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

Re: ITP: lirc, devfsd



On Sun, Apr 02, 2000 at 06:42:59PM -0800, Ethan Benson wrote:
> On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote:
> > > Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
> > > This one still needs a couple of problems ironing out first.
> > 
> > No offense, but I hope you realize the amount of effort that will be
> > needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
> > the amount of policy and technical bugs will be tremendous (permissions,
> > adding support for default compatibility devices, etc..).
> > 
> > I just don't want to see anyone go lightly into packaging devfsd. If you
> > aren't prepared to take on the responsiblity of what will most likely
> > become a base and essential package, leave it for some one else to do.
> 
> I hope debian is not planning on `forcing' [0] the use of devfs with 2.4,
> last i checked it was still a compile time option (and experimental at
> that) there are some of us who don't care for devfs and do not wish to
> use it.
> 
> [0] read making it exceedingly inconvenient to forgo or disable devfs
> in 2.4 kernels, for example neglecting to maintain or provide a real
> (non-devfs) working /dev directory.

No this is not an option. There will remain a real /dev for (an I presume
and support this particular viewpoint, but it has not been set in stone as
of yet, and wont be until potato is out of the way, and 2.4 is in woody)
atleast woody, and most likely the release after that. I would hope that
we can have a completely devfs system for the release after woody, simply
because it is the way that everything is going, and it is the Right Way.

Note that makedev can create all of the base devices with one simple
command. This makes it quite simple to get rid of devfs, even in the
future if we ever do decide not to provide it by default on later
distributions (in fact this can probably be scripted, so that if the
system boots without devfs enabled, makedev will create everything needed
on the fly).

However, people will want to use devfs, and therefore devfsd will be
needed in order to support the transition (without it, most programs will
fail to find the new device locations). I am pretty sure that devfs will
be used extensively in boot-floppies. The main reasons being that the
rootdisks will be smaller without having to contain hardcoded device
nodes. Secondly, it is easy to parse out what the available hardware is
since the device nodes are only created when a driver actually finds the
device and enables it (i.e. /dev/cdroms/cdrom0 wont exist unless there is
actually a cdrom device). Since the boot-floppies are self contained, it
wont even need devfsd for the installation program, since all the device
paths can be made to work with devfs' setup.

Again, these are my opinions alone, and nothing has been decided, but
devfs will come of age, and we need to support it, and that will mean some
work for the devfsd maintainer, whoever that may be.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`     bcollins@debian.org  --  bcollins@openldap.org  --  bmc@visi.net     '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'


Reply to: