[linux-elitists] [doc@ssc.com: [Fwd: Plug 'n' Pray to Plug 'n' Play: What's it Going to Take?]]

Greg KH greg@kroah.com
Thu Apr 20 13:48:24 PDT 2006


On Thu, Apr 20, 2006 at 11:25:49AM -0700, Aaron Burt wrote:
> 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.

Yes, you can now add device ids to the kernel after the driver is
already loaded, no code changes or rebuilding needed.  I think some
distros have a pretty gui tool that lets you do this without having to
muck around in sysfs yourself.

> > > [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.

The id files come directly from the kernel drivers themselves.  That way
they never get out of sync or are out of date.  This is _much_ better
than the way other operating systems do it...

> > 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
> and version.

Yes, there's always a delay like this.  But 6 months later, it all "just
works" for your customers.  And in the meantime, like you mentioned, you
can always just offer up a stand-alone kernel module package that builds
and runs just fine.

For some reason the network and scsi people don't have a problem with
releasing drivers before hardware is availble, and that's one of the
most competitive markets around.  Why would your device and market be
any different?

> Also, many products are supported simply because they're using stock
> glue ASICs with existing kernel support and talk standard protocols.

Yes, USB has been a _big_ success in regards to this.

> > > - 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 network cards don't have the lifespan of a fruit fly these days?
Again, what makes your market so much different from all others?

> And I won't even try to address products that need to supply user
> software to be useful.  Ugh, and documentation!

Ah, well, just include the user software on the cd like you do for other
operating systems.  We are no different there than anyone else.

> > 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.)

It doesn't rain that much here.  Well, compared to CA, yes, but that's
an unfair comparison...

thanks,

greg k-h



More information about the linux-elitists mailing list