[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

subarch debacle



After hours of tense negotiations with the Cabal it seems that I was in
error about how subarchitectures will work.

In the ensuing brouhaha, I concoted a mildly less shit scheme, I think
though am not certain, for expressing hardware.  In this revelatory new
scheme, we'd have names like this: acorn.a5k, acorn.riscpc,
acorn.archimedes, footbridge.netwinder, etc., etc., etc., etc..

We'd take the words `subarchitecture', `platform', `major', `minor',
and any other cool-sounding words you can think of, and combine and
permute them in various ways to describe both the first part, the latter
part, and the juxtaposition of the two (say, `subarchitecture' can refer
to the major part, `platform' to the minor one, whatever).  We can join
them with, I guess, either a dot (`.') or a hyphen (`-') or anything
else anyone thinks especially appropriate.  A slash would be a bad idea,
I think.

You can then invoke a script to spit out either of the two principal parts
or their conjunction.  In `update-modules', for instance, you'd apply the
major aliases file first, then the full one.  I imagine that for footbridge,
you wouldn't even bother; you'd just have /etc/modutils/arch/arm.footbridge.
In fact, apparently update-modules does this already, so long as we feed
it an appropriate string.  Great.

However, perhaps some future freakoid Acorn-like hardware will emerge with
a new sound chip.  For that, you could have `alias sound vidc20' in your
arm.acorn file, and `alias sound freakoidchip' in your arm.acorn.freakmachine
file.

There is one obvious variation to this proposed scheme: we could have
three, or indeed an infinite number of parts.  The follow-on variation
is that no part is subordinate to each other; thus each part encodes a
`capability' of the hardware, for example: `acorn.26.i2ctime.vidc1....'
or something.

If you think this is boring, you're right.  However, while the powers
that be are very clear what they /do not/ want, the only real suggestion
I've had so far is `make a /proc/hardware interface', which could
potentially list these sorts of `capabilities' or whatever.  I did try
and explain that I didn't think that was likely.

I imagine everyone's thoroughly sick of me whining on about this now.
If you all keep your humours active for a little while longer that would
be great.

If some feedback came in about what to do before I go ahead and implement
something based on my brain-damaged visions, that would be even better. ;-)

c.




Reply to: