[linux-elitists] [email@example.com: [Fwd: Plug 'n' Pray to Plug 'n' Play: What's it Going to Take?]]
Thu Apr 20 11:25:49 PDT 2006
On Thu, Apr 20, 2006 at 09:39:55AM -0700, Greg KH wrote:
> On Wed, Apr 19, 2006 at 10:49:36PM -0700, Aaron Burt wrote:
> > What Could Be Done:
> > - Central, well-maintained registry for mapping PCI/USB IDs to drivers,
> > both in-kernel and out-of-kernel.
> Huh? What would this help with?
Backwards- or otherwise-compatible devices that came out with new
PCI/USB IDs since the pci.ids in your kernel was last updated. I see
now that it's outside of the kernel, so if your distro is good about
keeping it updated, you're fine.
> > [hotplug blah blah blah]
> You do realize that Linux supports this today. You plug in a new
> device, and it automatically loads the proper driver based on the type
> of device it is. The kernel and userspace already do this just fine.
True, yay hotplug. I was talking about extending hp to use a 'net
registry (or at least a local cache.) Looks like I'm behind the times,
assuming the IDs files are carefully maintained.
> And Linux does _not_ support out-of-kernel drivers easily, and we do so
> for a very good reason. You need to get that driver into the kernel
> tree and then everything will be just fine.
Yup, and you need working support on existing customer systems from the
day you release the gizmo, not from when you (a) get clearance from
Marketing to even peep about it in public, (b) start the process of
getting it merged, (c) merge it (assuming you didn't accidentally breach
etiquette or step on any toes) (d) wait for the distro vendors to
validate the kernel version into which it's been merged and also add
your new firmware and/or userspace into their current package set, (e)
wait for your customers to get around to upgrading to the new kernel and
userspace, assuming that it's even availible with their current distro
Luckily, 2.6 includes kernel headers in /lib/modules, so if the machine
has a C compiler (tcc is small enough to always have around) a
source-based driver should install easily using a standard Makefile.
Also, many products are supported simply because they're using stock
glue ASICs with existing kernel support and talk standard protocols.
> > - Easy mechanism for incorporating out-of-kernel drivers into a running
> > system. I think it's a documentation issue, at this point.
> No, it's educating the developers that they should not be doing this :)
Good for long-term products, useless if your product goes from release
to EOL in less time than it takes to get a driver from LKML announcement
to a shipping distro's kernel.
And I won't even try to address products that need to supply user
software to be useful. Ugh, and documentation!
> > - A lab or something that helps with getting new gizmos to coders,
> > teaches coders how to make and maintain drivers, makes sure there
> > *are* maintainers, perhaps provides reverse-engineering equipment and
> > expertise, and hosts bake-offs and other compatibility testing stuff.
> OSDL is trying to start to provide this kind of functionality (the "get
> new gizmos to coders" part),
And good on yer for that.
> Just put a simple penguin on the box and say "works with Linux". I've
> seen it all the time on things ranging from scsi cards to USB flash
Pree-zactly. More of that, please, especially for in-kernel-supported stuff.
> And yes, we do seem to have a ton of Linux jobs here in Portland...
Yeah, but it RAINS ALL THE TIME! (Sorry, Oregonian protective reflex.
We do want more Linux folks here, even if some of them *are* Californians.)
More information about the linux-elitists