login
Header Space

 
 

Linux: Continuing To Debate devfs and udev

September 15, 2005 - 8:47am
Submitted by Jeremy on September 15, 2005 - 8:47am.
Linux news

The debate continues regarding the removal of the kernel space devfs in favor of the user space udev, though less people seem concerned about the idea. Linux devfs was written by Richard Gooch and merged into the 2.3.46 kernel in February of 2000. Greg KH began developing udev in 2001 [story], working to implement the same functionality as devfs, but in userspace. A resubmission of a patch intended to remove the unmaintained devfs from the kernel [story] spawned a renewed discussion of the potential merits of keeping devfs.

Mike Bell titled his arguments the "devfs vs udev FAQ from the other side", summarizing some differences between the two systems, and listing potential advantages of each. Robert Love [interview] contested some of his claims for devfs, pointing to the more modern features in udev, "what modern system, though, could survive without hotplug and sysfs and netlink?" Mike replied, "devfs's removal from the kernel isn't going to end my life, no. In fact it won't even stop me using linux. But it makes my job harder and more expensive, and as my little FAQ explains I don't feel I'm getting anything out of the deal."


From: Mike Bell [email blocked]
To:  linux-kernel
Subject: devfs vs udev FAQ from the other side
Date:	Wed, 14 Sep 2005 17:51:06 -0700

devfs vs udev
From the other side

Presuppositions (True of both udev and devfs):
1) Dynamic /dev is the way of the future, and a Good Thing
2) A single major/minor combination should have only a single device
node, its other names should be symlinks. If you don't do this, you
break locking on certain classes of applications, among other things.

The above are uncontentious as far as I know. I believe Greg KH has
stated both. If you feel otherwise, please explain why.

Differences:
1) devfs creates device nodes from kernel space, and creates symlinks
  for alternative names using a userspace helper. udev handles both tasks
  from user space, by exporting the information through a different
  kernel-generated filesystem.

devfs advantages over udev:
1) devfs is smaller
  Hey, I ran the benchmarks, I have numbers, something Greg never gave.
  Took an actual devfs system of mine and disabled devfs from the
  kernel, then enabled hotplug and sysfs for udev to run.  make clean
  and surprise surprise, kernel is much bigger. Enable netlink stuff and
  it's bigger still. udev is only smaller if like Greg you don't count
  its kernel components against it, even if they wouldn't otherwise need
  to be enabled. Difference is to the tune of 604164 on udev and 588466
  on devfs. Maybe not a lot in some people's books, but a huge
  difference from the claims of other people that devfs is actually
  bigger.

  And that's just the kernel. Then because your root is read-only you
  need an early userspace, and in regular userspace the udev binary, and
  its data files, all more wasted flash (you can shave it down by
  removing stuff you don't need, but that's just more work for the busy
  coder, and udev STILL loses on size).

  On the system in question (a real-world embedded system) the devfs
  solution requires no userspace helper except for two symlinks which
  were simply created manually in init, and could have been done away
  with if necessary.

2) devfs is faster
  Despite all the many tricks that can be used to speed up udev (static
  linking, netlink, etc) devfs is still dramatically faster. On a big,
  bloated, slow-booting distribution system you may not notice so much,
  but when even your slowest booting systems are interactive in under 5
  seconds using devfs, this is quite significant time loss.

3) devfs uses less memory
  Check free. sysfs alone does udev in and that's just the kernel stuff
  that's always there.
  
  Also, the user space stuff may not have to run at all times in all
  configurations, but on a system without swap and with long-running
  apps, all that matters is its PEAK memory usage. If my app takes x MB
  and my kernel takes y MB it doesn't MATTER that udev is only running
  for one second, I still need more than x+yMB of memory.


udev advantages over devfs:
1) udev has all sorts of spiffy features
  Sure, but having device nodes exported directly from the kernel in no
  way stops you from having those spiffy features. The problem is that
  udev is doing two separate tasks, and it's easy to confuse the one it
  should be doing with the one it shouldn't.

2) udev doesn't have policy in kernel space
  Well, that's a bit of a lie. sysfs has even stricter policy in kernel
  space. What he MEANS is that udev exchanges hard-coded but symlinkable
  /dev paths for hardcoded sysfs paths, moving the hard-coded kernel
  policy from one filesystem to another.

  This argument is really the only architectural reason to go with udev.
  At all. If you really believe that the ability to name your hard drive
  /dev/foobarbaz is vital, and absolutely can't live with merely having
  /dev/foobarbaz be a symlink to the real device node, then you need udev.
  The devfs way of handling this situation was a stupid, racey misfeature
  and rightly deserves to die horribly.

  That said, read my comments on why flexible /dev naming is actually a
  bad thing and think very, very carefully about whether you actually want
  this "feature" at all. Symlinks are your friend.

3) devfs is ugly
  Part of this is true, and part of this is just the perspective of
  certain people (Greg has this fascinating world view where code
  required for devfs is garbage, and code required for udev is core
  kernel code and doesn't count against udev, which allows him to say
  udev is smaller.)
  
  The legitimate comments about devfs being ugly... well, how many
  subsystems which have been largely untouched for similar periods of
  time aren't even uglier? TTY stuff? And it's very hard to find a
  maintainer for a subsystem when it's "obsolete", patches that change
  its behaviour aren't accepted, and certain people are so vocally
  opposed to its very existence. Who wants to throw away their time
  writing code that won't even be considered, only to be hated for it?

4) devfs is unsupported, udev isn't
  True that. And even people who've tried to maintain devfs get turned
  away. So unless this document causes a few people to reexamine the
  need to remove devfs, you can reasonably assume that udev will be the
  only way to run a linux system very shortly (static /dev is already on
  its last legs). Me, I'll be disappointed if this happens, because as
  the above document indicates, I still think kernel-exported /dev is
  better (and not because I'm a lazy user-space-hater, Greg. :) ).


From: Robert Love [email blocked] Subject: Re: devfs vs udev FAQ from the other side Date: Wed, 14 Sep 2005 21:08:38 -0400 On Wed, 2005-09-14 at 17:51 -0700, Mike Bell wrote: > devfs advantages over udev: > 1) devfs is smaller > Hey, I ran the benchmarks, I have numbers, something Greg never gave. Actually, there are not many numbers in this email. > Took an actual devfs system of mine and disabled devfs from the > kernel, then enabled hotplug and sysfs for udev to run. make clean > and surprise surprise, kernel is much bigger. Enable netlink stuff and > it's bigger still. udev is only smaller if like Greg you don't count > its kernel components against it, even if they wouldn't otherwise need > to be enabled. Difference is to the tune of 604164 on udev and 588466 > on devfs. Maybe not a lot in some people's books, but a huge > difference from the claims of other people that devfs is actually > bigger. What modern system, though, could survive without hotplug and sysfs and netlink? You need to have those components, you want those features, anyhow. So your comparison is unrealistic. Your user-space argument is better. Is ndevfs not sufficient? Robert Love
From: Mike Bell [email blocked] Subject: Re: devfs vs udev FAQ from the other side Date: Wed, 14 Sep 2005 19:09:36 -0700 On Wed, Sep 14, 2005 at 09:08:38PM -0400, Robert Love wrote: > Actually, there are not many numbers in this email. True, but two is more than zero. If they're going to do some good, I can always make more to show exactly how much udev slows down a boot and such. But at this point I have my doubts as to whether any benchmarks will change people's minds. > What modern system, though, could survive without hotplug and sysfs and > netlink? You need to have those components, you want those features, > anyhow. This is a modern system. As I took great pains to point out, that's an actual embedded system whose .config I copied and slightly modified for the test. > So your comparison is unrealistic. Not really. sysfs has a few uses now, but there are still virtually no embedded applications of it. Hotplug is nice for things whose hardware change, but useless for anything else (unless you need udev). Even on my notebook I only use it for the event from my CF port. Note that I'm not suggesting any of those features be removed from the kernel, merely that they should count against udev's totals when the system in question has no other use for them. And I don't see who else is making the argument for a couple of kB apart from exactly the sort of people who are disabling these features. There's a reason the -tiny patchset introduced the ability to disable sysfs, it isn't always needed and it does take up a lot of memory and bloat the kernel. > Your user-space argument is better. Is ndevfs not sufficient? Nope, unfortunately. If you read my initial response I was quite thrilled. But once I realized the limitations of ndevfs I changed my tone. The devfs hooks are still required to provide appropriate names, and it is these I'm most interested in saving.
From: Robert Love [email blocked] Subject: Re: devfs vs udev FAQ from the other side Date: Wed, 14 Sep 2005 23:17:50 -0400 On Wed, 2005-09-14 at 19:09 -0700, Mike Bell wrote: > Nope, unfortunately. If you read my initial response I was quite > thrilled. But once I realized the limitations of ndevfs I changed my > tone. The devfs hooks are still required to provide appropriate names, > and it is these I'm most interested in saving. If you can survive without modernism, why can't you survive without devfs? Why do you need it? Robert Love
From: Mike Bell [email blocked] Subject: Re: devfs vs udev FAQ from the other side Date: Wed, 14 Sep 2005 21:13:34 -0700 On Wed, Sep 14, 2005 at 11:17:50PM -0400, Robert Love wrote: > If you can survive without modernism, Features I don't need are "modernism"? Who defines what's "modern" and what's merely "useless"? Some things in newer kernels are very, very useful. Even sysfs is useful on some of my systems. But no, I generally try to avoid turning on features that I'm not even going to use on a given system. Do you install things you're not going to use on your machines? Maybe two or three different SQL servers, just to be extra-modern? Especially when I'm paying for every megabyte of flash x1k or x10k, I don't want to waste it on a bunch of unused kernel->userspace interfaces just to prove how incredibly hip to the latest linux fads I am. > why can't you survive without devfs? Why do you need it? Why can't you read any of the many threads on this subject where I explained this already? :) devfs's removal from the kernel isn't going to end my life, no. In fact it won't even stop me using linux. But it makes my job harder and more expensive, and as my little FAQ explains I don't feel I'm getting anything out of the deal (remember, udev's naming features are different to udev's device node creation, there's no reason you can't have one without the other).



Related Links:

Is it just me,..

September 15, 2005 - 9:09am
alan (not verified)

Or does it sound like we have a new devfs maintainer?

I hope so, as I was never con

September 15, 2005 - 9:46am
Anonymous (not verified)

I hope so, as I was never convinced as to the benefits udev is supposed to bring over devfs. Also, as I was getting the hang of devfs (I use Debian, not exactly a bleeding edge distro) someone decided it was crap and should be deprecated. Not fair. :-)
I say include both and let the users decide!

"Let the users decide"

September 15, 2005 - 11:11am
Anonymous (not verified)

This is a nice thought, but most users aren't really qualified to decide. Even considering those that may be, these guys can still make a far better decision. There are many issues here that have nothing to do with users, as well. (Maintainability, how it fits in with the current infrastructure, etc.)

Actually, users CAN decide. I

September 18, 2005 - 2:14pm
Alex Tanner (not verified)

Actually, users CAN decide. I'm a Linux user and I don't like udev or devfs. I'd rather there be a 'pseudofs' filesystem covering /dev, /proc and /sys, but nobody has thought of the idea yet. If I could program in C/C++, then I would have implemented this ages ago.

Keyword: *informed* decision

September 19, 2005 - 2:26am
Anonymous (not verified)

n/t

re: Is it just me?

September 15, 2005 - 11:12am

I'm afraid it's just you.

I also want to know!

September 15, 2005 - 11:48am
Anonymoose (not verified)

I think Mike has some very good points here. He actually uses this stuff where it is important.

I am also waiting for a reasonable argument why udev is better than devfs. I understand the implementation is better/nicer/maintained/whatever, but I want to know which design is better.

So far, udev on my desktop box has been playing catching-up with my old devfs setup. I had to do a lot of manual work to get static naming for my hard disks etc. which devfs provided out of the box.

Still udev has one problem: It leaves nodes behind after the devices are removed. They (some? all?) even survive system reboots! So I have lots of partitions visible in /dev which I removed a long time ago.

Someone has to make better argument against devfs. (If someone could explain how to fix my desktop I'd appreciate that, too.)

I think that Linus' position

September 15, 2005 - 12:08pm
Anonymous Persona (not verified)

I think that Linus' position has never been 'it's used by a person so it's good'. Linus has always maintained that his kernel [read: HIS kernel] should have features useable by the widest range of people. When big companies, or little ones demand a feature, he doesn't just cave to them. He wants to 'see' a demonstrated need by the average joe, etc, etc, etc.

Devfs has had a cursed life. People who 'know' have always hated it. Al Viro, HPA, even Alan Cox never was very excited about it. It was doomed from the beginning I think, and I feel sympathy for people who are pissed about this.

'Let the users decide' is fine in theory, but in this case kernel devs are saying it's not practical. Let the user decide literally means this: Let the user maintain thier own patch set. Does anyone maintain an 'embedded tree'? That would be the best place for all of this.

Finally, my pro-udev remark: this week, i finally eliminated pcmcia-cs from all of my laptops. That is hot. (No treally udev, but sysfs, udev and hotplug)

On Topic: Use a ramfs filesy

September 15, 2005 - 12:09pm
Anonymous Aagin (not verified)

On Topic: Use a ramfs filesystem for /dev. It's pretty easy.

future of static /dev?

September 16, 2005 - 4:16am

| Use a ramfs filesystem for /dev. It's pretty easy.

That means creating static /dev entries. In his mail Mike Bell noted:
(static /dev is already on its last legs). I guess he suspects
it is next in line for removal... Is he right? - I realize one could
not totally remove the possibility of static /dev without drastic changes to
how devices are accessed, but making all device numbers dynamic and
unpredictable would have much the same effect.

>Someone has to make better a

September 15, 2005 - 12:12pm
Anonymous Guy (not verified)

>Someone has to make better argument against devfs. (If someone could
> explain how to fix my desktop I'd appreciate that, too.)

Use a techology that applies: EVMS. I use it on a number of systems to eliminate the problem of 'moving' disks around etc. It works great.

http://evms.sf.net

Most distros include support.

How?

September 15, 2005 - 4:49pm
Anonymoose (not verified)

That's a good idea. How do you boot from it? Which versions of lilo and grub can boot from an EVMS volume? What types of striping and mirroring is supported? Do you need to do a two-stage boot via an initrd image and pivot root? Which types of file systems can host the kernel and initrd image inside the EVMS volume? I'd love any assistance on this since the docs are a bit thin (which is an understatement).

GIYF (Google is your friend)

September 15, 2005 - 6:39pm
Anonymous Barstard (not verified)

First off: Google is your friend. Everything I am about to say can be learned from Google. http://google.com

> That's a good idea.
>

> How do you boot from it?

You need a boot volume, it can be a mirror or a straight volume.

> Which versions of lilo and grub can boot from an EVMS volume?

WTF cares? grub 0.9x works fine for me. You need a single volume or a mirror volume in order to use evms with the boot loaders. You use an initrd because you have to init evms from userspace. More than that: http://evms.sf.net - They provide you with an initrd.

> What types of striping and mirroring is supported? Do you need to do
> a two-stage boot via an initrd image and pivot root? Which types of
> file systems can host the kernel and initrd image inside the EVMS
> volume? I'd love any assistance on this since the docs are a bit
> thin (which is an understatement).

Who am I, your mother? Read the docs, and mess around with it. SuSE at least has a nice installer setup for it. I think that FC does as well. Busted Debian should work fine, and Gentoo is not terrible. Granted, you have a read the docs, but it's not that bad.

-->>>
Now, I don't know if you meant it, but whomever you are, you came off like and a**hole. If your really whiny, technology tends not to work for you anyway. Try a toaster oven to warm up on,then if that works, a TV w/ a remote control.

He asked some good and legiti

September 15, 2005 - 7:54pm

He asked some good and legitimate questions, so don't behave like a jerk. Either ignore him or be at least a bit polite.

He asked questions without reading TFL

September 16, 2005 - 2:43pm

I'd say he was writing intentional flamebait. Almost all of his questions are answered in either the EVMS user guide, or the EVMS install documentation.

For your benefit, his questions, paired up with links that answer them:
How do you boot from it?
Follow the instructions in http://evms.sourceforge.net/install/boot.html and http://evms.sourceforge.net/install/root.html

Which versions of lilo and grub can boot from an EVMS volume?
This one isn't in the documentation. However, LILO 22.7 is mentioned explicitly, and it says that "If you are using Grub as your boot-loader, the version that you are currently running will work fine." I've used grub 0.93 and 0.94 without trouble.

What types of striping and mirroring is supported?
http://evms.sourceforge.net/user_guide/#appxmdreg says that it supports RAID levels 0, 1, 4 and 5. It is clear from the rest of the user guide that, since RAID produces regions, you can build RAIDs on RAIDs to get things like RAID 10.

Do you need to do a two-stage boot via an initrd image and pivot root?
http://evms.sourceforge.net/install/root.html says you do, and tells you how to.

Which types of file systems can host the kernel and initrd image inside the EVMS volume?
Any that EVMS supports. See http://evms.sourceforge.net/user_guide/#FSIMsuppevms

I disagree that the inability

September 17, 2005 - 2:53pm

I disagree that the inability to read automatically means he's intentionally flamebaiting. That his questions are answered on those sites doesn't mean it are bad questions. On the contrary, it possibly means his questions are worth answering.

Just give him the link to the evms site and say they're all answered there. But answering his questions anyway when you think they're not worth answering and making yourself seem like a fool by behaving unnecessarily rude isn't the way to go IMHO.

Only thing he did really wrong is putting the blame elsewhere after not finding the answers for himself.

Sorry, question remains

September 18, 2005 - 4:41pm
Anonymoose (not verified)

Inability to read? What a most excellent way of helping people. Of course I had read those exact web pages since that is the most obvious documentation. Those pages describe some very basic lilo/grub config lines, which the user hopefully already knows or it's time to read those docs instead. Nothing further is even touched upon. You still have no idea what versions have support for mounting EVMS volumes, on which architectures it works, which raid levels are supported, which file systems are supported, how the initrd images are fetched etc etc. Which is what I tried asking about since this is where someone pointed to EVMS as a solution.

Gentoo?

September 15, 2005 - 5:26pm

Still udev has one problem: It leaves nodes behind after the devices are removed. They (some? all?) even survive system reboots!

You're not perchance using Gentoo and the weird device-tarball thing?

Re: Gentoo?

September 16, 2005 - 11:55am

Gentoo put udev in portage in very early stage of udev develepment. Then it was necesary to do the "weird" tarball to keep nodes for drivers that did not use sysfs yet.A good example was the nvidia x11 driver.

How to get rid of it?

September 18, 2005 - 4:44pm
Anonymous Cowboy (not verified)

Great, everyone has to suffer because some non-free software isn't up to par.

So how do you get rid of the Gentoo tar-ball-thingy?

Gentoo udev

September 18, 2005 - 7:58pm
Anonymous (not verified)

In /etc/conf.d/rc there is a line: RC_DEVICE_TARBALL="yes"
Just change the "yes" to "no".

UDEV = WIndow Vista?

March 1, 2007 - 8:49pm
Anonymous (not verified)

Because if there's one thing Linux should aspire to, its to be as complex and slow as Vista. Users notice 'slow' and slow = crap. K.I.S.S.

udev leaves files behind?

September 16, 2005 - 1:09pm
Anonymous (not verified)

> Still udev has one problem: It leaves nodes behind after the devices
> are removed. They (some? all?) even survive system reboots! So I
> have lots of partitions visible in /dev which I removed a long time
> ago.

I've never seen this. Fedora mounts their /dev as a tmpfs filesystem,
so you basically get the same state always. Can you be more specific
about the problem? Certainly the ability to manually create device
nodes in /dev is a udev feature, not a bug...

Don't you think this debate b

September 15, 2005 - 1:16pm
Anonymouse! (not verified)

Don't you think this debate boring as hell? It has been way too over-discussed.
Don't just talk about it; do something.
Remove the current dumbed-down devfs because udev clearly beats it. And if you liked devfs (re)write a better version of it and volunteer to maintain and everyone will benefit.
That's what open-source is about.

Aw, but I like a good fight e

September 15, 2005 - 4:37pm
Anonymous (not verified)

Aw, but I like a good fight every once in a while...

It's been done, the patches w

September 16, 2005 - 6:58am
Anonymous (not verified)

It's been done, the patches were rejected.

> It's been done, the patches

September 21, 2005 - 10:59am
Anonymous (not verified)

> It's been done, the patches were rejected.

That's what linux is all about.

Well I don't run udev or devf

September 15, 2005 - 2:53pm
MisterW (not verified)

Well I don't run udev or devfs. And why should I run a hotplug demon to manage my devices? Seems like overkill to me.
I reduced my makedev-script to not build thousands of devices. You can just as easily manage to get the job done with (10's or) hundreds of devices.
And still my modern system runs kernel 2.6.13 without any device manager. I also don't mount sysfs, devpts or shm.
Now can anyone give me a good reasons what the benefits are when I mount all that stuff or use udev?

Not for devfs

September 15, 2005 - 4:40pm
Anonymoose (not verified)

You don't need to run a hotplug daemon or any other daemon for devfs. You just enable it in the kernel and mount /dev (or enable the boot mount for devfs), and it's all working as expected. It saves you the job of messing with makedev and automatically shows you all the devices that are connected and working.

But with udev....

September 15, 2005 - 7:55pm
Anonymous Barstard (not verified)

Take the case of a desktop. udev integrates nicely with pam_console, hal and dbus and now pcmcia, and produces the nice effect of 'integrated' device permissions management for desktop users. That in and of itself is hot.

Great...

September 18, 2005 - 4:45pm
Anonymoose (not verified)

That is a good feature with udev!

But there is no reason devfs couldn't do the same.

devpts is for pseudo-terminal

September 15, 2005 - 8:01pm

devpts is for pseudo-terminal support, how do you run your xterms without it? Or do you use the old terminal stuff? I'd disable support for the legacy stuf and just mount devpts.

shm is used for posix shared memory, so if you happen to run an app that uses that it will fail. But if you know you don't have any program which uses it then not mounting it is fine.

Well I can run xterms and ate

September 16, 2005 - 8:30am
MisterW (not verified)

Well I can run xterms and aterms etc.
And maybe it's because because I don't have a dev entry for devpts.
Never encountered and app which needed shm btw

I bet you run libc5 for every

September 19, 2005 - 4:57pm
Anonymous (not verified)

I bet you run libc5 for everything, too. You know, technological advancement does have a place. Every other OS under the Sun (hell, even Solaris) does some sort of automatic device management. Linux now has a robust implementation, and if you've been ignoring it, you're really missing out. I stick in a USB memory key, it gets mounted. Bam.

when you say shm, are you tal

September 21, 2005 - 11:08am
Anonymous (not verified)

when you say shm, are you talking about CONFIG_SHMEM ?

looks like it's part of tmpfs.....

The shmem is an internal filesystem used to manage shared memory.
It is backed by swap and manages resource limits. It is also exported
to userspace as tmpfs if TMPFS is enabled. Disabling this
option replaces shmem and tmpfs with the much simpler ramfs code,
which may be appropriate on small systems without swap.
Symbol: SHMEM [=y]
Prompt: Use full shmem filesystem
Defined at init/Kconfig:307
Depends on: MMU && EMBEDDED
Location:
-> General setup
-> Configure standard kernel features (for small systems) (EMBEDDED [=y]) │

Doesn't sysfs

September 16, 2005 - 6:39am
Damjan (not verified)

Doesn't sysfs already contain the necessary information for creating the node files? I guess a devfs-ng would just need to export those information in a suitable manner.

And why do we still need device nodes?
Isn't this all solvable by having special files (like sysfs already has) that directly do IO to the drivers?

Not again

September 16, 2005 - 4:06pm
SlackUX (not verified)

I cannot believe someone has taken the time to TRY and prove that devfs is better. udev works and works best as Greg setout, It achieves all the goals what devfs never did proper. Come on, can he not do anything better than try disprove udev and work on something worth while, like help develop udev instead of moaning about it.

Yeah, I don't get it either.

September 17, 2005 - 10:43am
Anonymous (not verified)

Yeah, I don't get it either.

I switched from devfs/gentoo to udev/LFS. I can't say my /dev has ever been so clean as right now. The only thing I can remember doing in there was creating a symlink for my dvd.

Linux: Continuing To Debate devfs and udev

September 18, 2005 - 2:20pm
Alex Tanner (not verified)

I don't like devfs or udev. I would rather there be a pseudofs filesystem to cover /dev, /proc and /sys. In fact, if I could program in C, I would have created it ages ago. It makes so much sense to consolidate /dev, /proc and /sys into a single virtual filesystem, rather than treat them individually.

It makes so much sense to con

September 25, 2005 - 3:40pm

It makes so much sense to consolidate /dev, /proc and /sys into a single virtual filesystem, rather than treat them individually.

Huh? All 3 of those filesystems have different jobs, how could it possibly make sense to consolidate them?

Linux: Continuing To Debate devfs and udev

September 18, 2005 - 2:27pm

I don't like udev or devfs. I just wish someone would implement a 'pseudofs' filesystem that consolidates /dev, /proc and /sys into a single filesystem, because I can't program in C!

multimedia and missing DVD drives

September 18, 2005 - 6:36pm
StoelnNomenclature (not verified)

I am new to Linux (Unix) being a Windows person (who hates Microsoft) and know nothing about the technicalities of either devfs or udev - dont really want to either.

But is this the reason why I can never play DVD's on Linux? No matter what distro I use, when I fire up MPlayer of Xine it is unable to find the DVD drive.

I have never understood why Unix makes such a dogs breakfast of naming resources. I have three optical drives, and they all seem to have different names (e.g. /dev/cdrom0, /dev/hda1, etc) on each distro, sometimes different names on a weekend.

When is someone going to actually fix this idiotic mess?

No matter what distro I use,

September 18, 2005 - 8:43pm
Anonymous (not verified)

No matter what distro I use, when I fire up MPlayer of Xine it is unable to find the DVD drive.

The name of the DVD drive will probably have been mentioned in the kernel's boot output. Try dmesg|grep DVD and then you can provide the right device name to mplayer with the -dvd-device option. Or you can make /dev/dvd a symlink to that device and then xine and mplayer will pick it up automatically.

I have three optical drives, and they all seem to have different names (e.g. /dev/cdrom0, /dev/hda1, etc) on each distro, sometimes different names on a weekend.

Some of those names (like /dev/cdrom0) will be aliases for the real device. /dev/hda1 is the first partition on the first IDE device and is unlikely to be one of your optical drives. But, yes, the lack of policy between distros is unfortunate.

... know nothing about the technicalities of either devfs or udev - dont really want to either

If you're not interested in the technicalities of kernel features then kerneltrap might be the wrong site to be following! ;-)

RE: multimedia and missing DVD drives

September 18, 2005 - 9:13pm
Anonymous (not verified)

No it's got nothing to do with it, besides it's illegal to unencrypt dvd's in this way, thats why Linux don't come with dvd playback(some euro contries it's illegal to supply the dvd playback package i.e thats why SuSE don't). You just need libdvdcss to get dvd playback thats all.

The naming of resources has never been a issue until now because of Linux on the desktop, both udev and HAL address this so that it's readable to the user.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary