Re: Discover and SBUS?
I went on vacation soon after sendin my message, and I completely forgot
about it. I've done some looking at discover 1.5 and 2.0, and I'm really
not sure what to do. Some difficulties:
* v1.5 and v2.0 have significant architectural differences. I would have
to commit to one.
* A number of bug reports relating to NMU fixes, pending uploads, and the
upstream release have been pending for six months or more. An unrelated
bugreport/patch I submitted two weeks ago has gotten no response.
* It doesn't look like OpenPROM provides guaraunteed fields for
identifying devices. It looks like 'name', 'vendor', 'model', and 'driver'
are sometimes sufficient. I'd like to probe SBUS by visiting each node in
the device tree and asking "Does this node have the properties 'name=foo,
driver=bar'? Does it have properties 'model=whiz, vendor=bang'". Is this
overkill? Have I misinterpreted the contents of OpenPROM?
* discover 1.5 is designed with the assumption that an installed device
provides identifying, numeric vendor and model codes for most
devices. The ide and scsi devices demonstrate how to incorporate a bus
that deviates from this scheme, and I could mimc that. But upstream
probably wouldn't support a 1.5 patch, and Debian seems inert anyway.
* discover 2.0 allows numeric and non-numeric vendor and model codes, but
doesn't allow the deviations. It looks like using the 'key-value' approach
would require some major reworking. But Debian hasn't adopted 2.0, so it
would trouble for noth.
On Thu, 10 Jul 2003, Ben Collins wrote:
> On Thu, Jul 10, 2003 at 09:01:15PM -0400, Tim Otten wrote:
> > I recently did a reinstall with Debian/unstable on an Ultra 5, and I was
> > pleased that the 'discover' package was able to configure most devices.
> > The only exception was the audio, an E/SBUS device identified as
> > "SUNW,CS4231" using the 'cs4231' module.
> > 'discover' doesn't have E/SBUS support, but the code for probing that bus
> > is basically available in 'prtconf'. Would it be worthwhile to extend
> > 'discover'? Or should I be using a different package, like kudzu? Would
> > any other Sparc hardware benefit from this?
> I can't see the harm in it. If you want it done, then by all means do
> it, and send the code to the author.
> Debian - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> Deqo - http://www.deqo.com/