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

Re: discover or alsa?

On Wed, Oct 13, 2004 at 08:18:45PM +0200, Marco d'Itri wrote:
> On Oct 13, Wouter Verhelst <wouter@grep.be> wrote:
> > > will probably become mandatory very soon (hint: udev) and needs anyway
> > > to support PCI hotplugging for systems with an hotplug PCI bus.
> > That doesn't have anything to do with coldplugging. Also, AFAIK, udev is
> Sure it does. Why waste time duplicating the infrastructure? Also,
> programs like kudzu and discover need a database, while hotplug is
> automatically up to date to the installed kernel. This alone should be a
> major argument in its favour.
> > far from the only /dev implementation in the kernel. I don't think it'll
> > suddenly be mandatory.
> devfs is dead, deal with this.

I wasn't talking about DevFS specifically. Note that, when DevFS was
accepted into mainline kernels, it was expected to be great and
wonderful. Allow me to be a bit sceptical regarding udev -- especially
given the .dev mess and related race conditions you mailed about a while

For the time being, I'm sticking to static /dev directories. It has
kernel-side issues, but it's well-established, and it works. I expect
many people will think the same way. Frankly, I'm not convinced udev is
going to be as popular as you seem to suggest.

> It has no future, and I expect it will be removed in the next two
> years.

So do I.

> To learn why udev will probably become mandatory, read the threads
> about this in the debian-devel@ archive.

Care to provide me with a reference?

> > > > Apart from that, there's also the 'canon' way of managing modules
> > > > (/etc/modules), and a number of other packages which will load modules
> > > > to be able to do what they're installed for (hardware driver support
> > > > packages such as the ALSA ones, but also stuff such as binfmt-support
> > > > and nbd-client).
> > > ALSA does not loads modules anymore,
> > ACPI.
> The ACPI modules are not related to hotplug, at least currently.

That can all change, at which point it'd suddenly have issues similar to
the issues ALSA had in the past. Your point?

> > > the other packages you mentioned do not load device drivers and are
> > > not relevant in this discussion.
> > They load modules. This is a suggestion about managing how modules are
> > loaded.
> non-device modules are not related to hotplug either.

Again, I was talking about more than just hotplug.

Automagically configuring stuff is nice for desktop systems where those
that are allowed physical access to the system do not necessary have
root privileges. It isn't necessarily a good idea in, e.g., data

My point is that the proposed system would give a local admin the
ability to manage modules over packages. Even if you think udev is the
future and all the rest is crap, that doesn't have to mean everyone else
agrees with you, or that it's even true.

> > What's impossible about that?
> Impossible, not. Not needed and hard to deploy, yes.

Frankly, that sorta summarizes my opinion about udev. It probably solves
some issues at the kernel side of things, but from what I've seen, it
sure looks ugly.

Does that mean I should completely ignore it?

     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 -- with thanks to fortune

Attachment: signature.asc
Description: Digital signature

Reply to: