Re: CD writing in future Linux (stirring up a hornets' nest)

[Olivier Galibert <galibert@pobox.com>]

On Fri, Feb 03, 2006 at 04:06:13PM -0500, Phillip Susi wrote:
> Olivier Galibert wrote:
> >No, it isn't.  OTOH, udev maintains it, so I guess that's good enough.
> >It makes udev the kernel interface though.  I hope they now care about
> >compatibility (/dev/.udev.pdb vs. /dev/.udev/db/* anyone?).
> >
> 
> Yes, it is, where do you think udev gets it's information from?

The device node name?  From the rules in /etc/udev/rules.d/*.  Udev is
the one which creates it in the first place, deriving it in a
user-defined way from the sysfs information.  It does _not_ give back
that information to the kernel.  Maybe it should.


> >Bullshit.  If <x> is the only interface available to a kernel service,
> >then <x> is part of the kernel whether you like it or not.  Case in
> >point, the ALSA library.
> 
> Bullshit yourself.  If cdrecord is the only application for burning cds, 
> that does not make it the kernel interface for cds, and certainly does 
> not make it part of the kernel.  The kernel interface is the point of 
> interaction between user and kernel code, which is sysfs.

The kernel does not provide a cd burning service, only a scsi packet
transport service called SG_IO.

The kernel *does* provide a device enumeration service, only it does
it at this point through udev for reasons that are 50% technical and
50% political.  If you want to be able to use a 2.6 kernel with
hotplug devices udev[1] is mandatory.  As such, from an engineering
point of view, udev is part of the kernel even if it isn't in the
source tarball on kernel.org.  And for now it is the lowest level
interface to device enumeration.

  OG.

[1] Or hotplug, maybe.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/