|
Home > Archive > Debian Developers > April 2004 > udev device naming policy concerns
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
udev device naming policy concerns
|
|
| Tore Anderson 2004-03-04, 8:33 pm |
|
I'll just start by quoting Marco d'Itri (the udev maintainer) notes
about this subject from README.Debian:
> Naming policy
> ~~~~~~~~~~~~~
> The plan, so far, is to have the default configuration create devfs-like
> devices. Compatibility symlinks will be created for common devices for
> which the new names are still not used by defaults by programs, but the
> goal is to remove most of these links.
> If you think more aliases are needed or some aliases should be removed
> please discuss this with the udev debian maintainer.
> Feel free to submit an additional config file with more aliases or one
> with only old style devices.
(For those who haven't used neither devfs nor udev, this means that,
say, the first serial console device will be /dev/tts/0, probably with
an interim compability symlink at /dev/ttyS0.)
First of all, devfs is considered obsolete by the upstream kernel
maintainers. The devfs naming style (or devfs itself, for that matter)
has, as far as I know, never been the default way of of handing /dev,
nor has it been made the standard by any major distribution except
Gentoo. If I recall correctly, devfs went straight from being marked
as EXPERIMENTAL to OBSOLETE in the kernel config.
That we should adopt this obsolete naming scheme as the default concerns
me; I do not wish to see such radical decisions affecting the very core
of our distribution being made on a whim by individual maintainers. udev
seems overwhelmingly likely to become the default way of handling /dev on
GNU/Linux as it's being endorsed by the upstream kernel maintainers and,
well, is pretty XXXXing neat, IMHO. I'll wager we'll be using it as the
default for Sarge+1.
I'll also wager that if we go with the devfs naming style we'll be the
odd man out. The Linux kernel itself, and the upstream udev sources,
names the devices the standardized (ttyS0) style and doesn't, as far as
I know, have -any- plans to change that. The same goes for Red Hat, and
probably the most of the other major distributions. The only one I know
of that's adopted devfs as the default is Gentoo, and according to their
site they're about to ditch devfs (and I believe their udev package does
the exact oposite of ours and creates compability symlinks for those
already using the devfs names, and that they mean to get rid of it
completely after their users have had some transitioning time).
That we should decide to go in the oposite direction of what all the
other distributions (including the direction we ourselves are going at
the moment) and the upstream Linux folks go, is in my opinion
objectionable enough and should be decided in plenum (or in the absense
of a clear consensus, the tech-ctte).
That one of our goals shall be to eventually have changed all of our
packages to use the devfs-style naming style exclusively and have removed
the symlinks from the standard locations, thus having rendered ourselves
incompatible with every other major distributor (and that includes most
upstream sources that use device nodes directly), is absolutely
ludicrous. Not only is it a unrealistic goal, but I fail to see *any*
advantage accomplishing it will make.
When I requested a rationale for the change from Marco on IRC, the one
I got was, quote: "it's useful", and: "you can install your own rules
file anyway if you don't like them". While I agree that the devfs
naming style has some advantages over the standard naming style
(particulary regarding SCSI hard drives), the drawbacks on making it
the default surmount those by far. I strongly feel that our udev package
shouldn't deviate from the rest of the world. Those who require the
advantages non-standard device naming give should be the ones using
non-standard udev rules files.
Marco asked me to voice my concerns here on the list instead of
continuing the discussion on IRC, so, well, here they are. Comments
are welcome.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tollef Fog Heen 2004-03-05, 3:33 am |
| * Tore Anderson
| That one of our goals shall be to eventually have changed all of our
| packages to use the devfs-style naming style exclusively and have removed
| the symlinks from the standard locations, thus having rendered ourselves
| incompatible with every other major distributor (and that includes most
| upstream sources that use device nodes directly), is absolutely
| ludicrous. Not only is it a unrealistic goal, but I fail to see *any*
| advantage accomplishing it will make.
I think you are overestimating the problems. I used to run without
any compat symlinks, just devfs, and apart from the fact that you have
to fix inittab, it mostly Just Worked.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-05, 4:33 am |
| Tore Anderson <tore@debian.org> wrote:
> I'll just start by quoting Marco d'Itri (the udev maintainer) notes
> about this subject from README.Debian:
[color=darkred]
[...]
I think Tore has made a pretty strong case already I would like to
hear an answer to a simple "Why?" by Marco.
One of the major obstacles that kept devfs from being adopted by a
wider audience (besides the racing conditions) was its default naming
scheme, duplicating this in udev does not look advisable to me.
This is nothing personal, I have been using devfs since I switched to
2.4 (I am not using it when booting 2.6, as it is obsolete and devfsd
has not been updated).
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
|
|
| Chad Walstrom 2004-03-05, 12:34 pm |
| On Fri, Mar 05, 2004 at 11:44:00AM +0100, Claus Färber wrote:
> That's against Debian Policy, version 3.6.1.0, section 9.1.1.[1], which
> refers to the FHS, version 2.1, whose section 6.1.2.[2] refers to the
> LANANA /dev registry[3].
For these reasons and the ones listed previously in this thread, the
Debian udev package should NOT default to devfs. This does not limit us
in any way. udev is about flexibility, and a debconf configlet giving
the administrator the CHOICE would be the best solution. In the case
that the administrator choses non-interactive installations, the default
should be the EXPECTED behavior from the udev software -- the default
udev naming scheme.
--
Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
| |
| Tore Anderson 2004-03-05, 1:34 pm |
| * Tollef Fog Heen
> I think you are overestimating the problems. I used to run without
> any compat symlinks, just devfs, and apart from the fact that you have
> to fix inittab, it mostly Just Worked.
When I experimented with devfs and attempted to run without the symlinks
my system broke down to the point of not booting fully, due to the fact
that the devices where my system partitions was supposed to be located
(/dev/hda1 and such) wasn't available any longer. After having fixed
that I just found that many other things was broken, such as for instance
XMMS (due to the missing /dev/dsp and /dev/mixer), my floppy drive
was inaccessible (no /dev/fd0 either), and so on for almost every piece
of software using device nodes directly. It surprises me to hear that
you didn't run into such problems, but then again, I did my testing for
quite some time ago - things may have changed since then.
Anyway, my complaint isn't that it will be technically impossible to
build a system exclusively using non-standard device names, be it
devfs names or something else entirely, but rather that this attempt to
do so right now is undesireable and serves no good purpose.
The current naming scheme is, after all, a universally accepted and
ubiquitous standard, one which has been formalized by the Free Standards
Group, and one which no major player in the GNU/Linux arena seem intent
on changing in the foreseeable future. I believe we should have a very
compelling rationale at the table before deciding to stray from it.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2004-03-05, 4:33 pm |
| I demand that Andreas Metzler may or may not have written...
> Tore Anderson <tore@debian.org> wrote:
[color=darkred]
> [...]
> I think Tore has made a pretty strong case already I would like to hear an
> answer to a simple "Why?" by Marco.
While I can't speak for Marco, I can certainly say why I would do something
like this:
Some people are using devfs and may be using devfs-style device names.
Dumping these could break things for these people when they upgrade to udev,
whereas retaining them gives these people a chance to play with udev without
having to alter anything and revert to devfs if need be.
It's also possible that the devfs-style names could be lurking, forgotten, in
some configuration files... that said, maybe that's a good reason to *dump*
the devfs names. I'm not sure that the affected people would be happy about
it, though ;-)
FWIW, I'm running udev on my laptop without problems (kernel 2.6.2), but I'm
not running it on my desktop boxes. I plan to continue to use 2.4-series
kernels on one of them, but I'd quite like to run 2.6.x+udev on the other;
however, devfs it is for now because the DVB drivers don't yet support sysfs.
(Well, that and some odd process-hangs which look like what's reported in
<URL:http://marc.theaimsgroup.com/?l=lin...107697302004071>. I
should probably retry 2.6.2.)
> One of the major obstacles that kept devfs from being adopted by a wider
> audience (besides the racing conditions) was its default naming scheme,
> duplicating this in udev does not look advisable to me.
Let's just sum up the above as "compatibility reasons" :-)
> This is nothing personal, I have been using devfs since I switched to 2.4
<AOL>.
> (I am not using it when booting 2.6, as it is obsolete and devfsd has not
> been updated).
My impression is that it has, at least, been maintained. I think that it'll
be retained as long as 2.6 is maintained, but removed completely in 2.7. (Of
course, ICBW...)
--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)
He who cooks carrots and peas in same pot unsanitary.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gunnar Wolf 2004-03-05, 4:33 pm |
| Tollef Fog Heen dijo [Fri, Mar 05, 2004 at 08:40:46AM +0100]:
> | That one of our goals shall be to eventually have changed all of our
> | packages to use the devfs-style naming style exclusively and have removed
> | the symlinks from the standard locations, thus having rendered ourselves
> | incompatible with every other major distributor (and that includes most
> | upstream sources that use device nodes directly), is absolutely
> | ludicrous. Not only is it a unrealistic goal, but I fail to see *any*
> | advantage accomplishing it will make.
>
> I think you are overestimating the problems. I used to run without
> any compat symlinks, just devfs, and apart from the fact that you have
> to fix inittab, it mostly Just Worked.
Ummmm... I find this a bit hard to believe. I ran also with devfs for
some time, but depended on devfsd to translate everything to where
many programs expected them to be.
By sticking to the old naming scheme, we would not only not require
many maintainers (and eventually upstream developers) to modify their
code (and, by the way, the upstream developer would probably stick to
what makes sense to most distributions, not to our strange scheme -
more work for maintainers from now on), but we would stick to a
tradition that has proved to work for a very long time. Not only every
Linux distribution uses the old scheme of an almost-flat /dev, but
every Unix system (at least those I have worked with) have a similar
structure.
Greetings,
--
Gunnar Wolf - gwolf@gwolf.cx - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul Hampson 2004-03-05, 4:33 pm |
| On Fri, Mar 05, 2004 at 05:45:55PM +0100, Tore Anderson wrote:
> * Tollef Fog Heen
>
>
> When I experimented with devfs and attempted to run without the symlinks
> my system broke down to the point of not booting fully, due to the fact
> that the devices where my system partitions was supposed to be located
> (/dev/hda1 and such) wasn't available any longer. After having fixed
> that I just found that many other things was broken, such as for instance
> XMMS (due to the missing /dev/dsp and /dev/mixer), my floppy drive
> was inaccessible (no /dev/fd0 either), and so on for almost every piece
> of software using device nodes directly. It surprises me to hear that
> you didn't run into such problems, but then again, I did my testing for
> quite some time ago - things may have changed since then.
Things certainly have. For me, the big changes I had to make were fstab,
lilo.conf, inittab. Large chunks of Debian is already devfs-aware, (I
dunno about xmms but) mpg123 for example will try both /dev/dsp and
/dev/sound/dsp. And of course, alsa's modules appear in the same place
under both devfs and normal operation. Apart from things like rng-tools,
psaux-using devices and microcode.ctl (for which I've locally moved the
devices out of /dev/misc/ since that's a meaningless distinction to me,
and now I can set those packages back to default) I haven't had to hunt
for device nodes in years.... (Well, cdrecord complains that open by
devicename is unsupported, but it also dislikes ide devices so even if I
did supply the nodes it wanted, it wouldn't be happy)
> Anyway, my complaint isn't that it will be technically impossible to
> build a system exclusively using non-standard device names, be it
> devfs names or something else entirely, but rather that this attempt to
> do so right now is undesireable and serves no good purpose.
> The current naming scheme is, after all, a universally accepted and
> ubiquitous standard, one which has been formalized by the Free Standards
> Group, and one which no major player in the GNU/Linux arena seem intent
> on changing in the foreseeable future. I believe we should have a very
> compelling rationale at the table before deciding to stray from it.
I think the devfs naming scheme is better personally, as it gives you a
structured view of what's in the system, and a structured way of dealing
with devices... (IE v4l stuff lives in /dev/video, easy.)
On the other hand, I can understand your point about not migrating away
from the documented, standardised approach, (ugly as it may be :-)...
The current default files create nodes in the devfs places, and symlink
to the kernel names for the ide/scsi stuff. Maybe it ought to create
nodes with the kernel names, and symlink to the devfs-style names? After
all, local configuration is quite esay to change. (In my case, I just
whacked the %k from the scsi/ide strings since I'm migrating from
devfs)...
And/or provide examples of different schemes. I suspect the old-style
naming config file would probably be a one line udev.rules:
KERNEL="*" NAME="%k"
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
| |
| Paul Hampson 2004-03-05, 4:34 pm |
| On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
> I demand that Andreas Metzler may or may not have written...
[color=darkred]
> My impression is that it has, at least, been maintained. I think that it'll
> be retained as long as 2.6 is maintained, but removed completely in 2.7. (Of
> course, ICBW...)
Actually, as reported through kerneltraffic, it apparently hasn't been
updated by anyone for years. Everytime someone asks, insurmountable race
conditions are mentioned and everyone runs for the hills.
Of course, _I_CBW too. :-)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
| |
| Paul Hampson 2004-03-05, 5:33 pm |
| On Fri, Mar 05, 2004 at 10:19:05AM -0600, Chad Walstrom wrote:
> On Fri, Mar 05, 2004 at 11:44:00AM +0100, Claus Färber wrote:
>
> For these reasons and the ones listed previously in this thread, the
> Debian udev package should NOT default to devfs. This does not limit us
> in any way. udev is about flexibility, and a debconf configlet giving
> the administrator the CHOICE would be the best solution. In the case
> that the administrator choses non-interactive installations, the default
> should be the EXPECTED behavior from the udev software -- the default
> udev naming scheme.
Maybe it ought to look at the current /dev layout? That'd save a
question that's easily guessable. On the other hand, automating such a
choice (which I was considering suggesting as well) leads to hassles
in the conf-file handling, as something has to cease being a conffile.
A notification of some kind if devfs is detected for the user to install
the devfs configuration example file (yes, all kinds of assumptions in
that sentence) would be sufficient, since udev does _not_ start at the
end of postinst, so it's not too late. :-)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
| |
| Andreas Metzler 2004-03-05, 8:33 pm |
| Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
> I demand that Andreas Metzler may or may not have written...
[...]
[color=darkred]
> My impression is that it has, at least, been maintained.
I don't think so. From browsing linux-kernel the only change to
devfs' code that has happened recently is that the devpts-filesystem
now needs to mounted even if running devfs. Otherwise no maintainance
has happened because nobody capable of maintaining it wants to it and
at least some of the race-conditions are believed to be design-issues
and practically unfixable.
> I think that it'll be retained as long as 2.6 is maintained, but
> removed completely in 2.7. (Of course, ICBW...)
Yes, afaik that is the official plan.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| viro@parcelfarce.linux.theplanet.co.uk 2004-03-05, 9:33 pm |
| On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
> Some people are using devfs and may be using devfs-style device names.
> Dumping these could break things for these people when they upgrade to udev,
> whereas retaining them gives these people a chance to play with udev without
> having to alter anything and revert to devfs if need be.
.... and a lot of people never allowed devfs on their boxen. "But I luurve
devfs names" is not a reason to go against the standards and common practice
alike.
Make it a debconf question if you really want it; making it a default, let
alone unconditional, has no excuses - standard compliance alone is enough
to make that a bug.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tore Anderson 2004-03-05, 10:33 pm |
| * Andreas Metzler
> I think Tore has made a pretty strong case already I would like to hear
> an answer to a simple "Why?" by Marco.
* Darren Salt
> While I can't speak for Marco, I can certainly say why I would do
> something like this:
>
> Some people are using devfs and may be using devfs-style device names.
> Dumping these could break things for these people when they upgrade to
> udev, whereas retaining them gives these people a chance to play with
> udev without having to alter anything and revert to devfs if need be.
Attempts to help users who are going to make the transition from
devfs->udev are all well and good. That can easily be accomplished by
for instance providing rule files in /usr/share/doc/udev/examples/ which
will ensure the creation of symlinks from the devfs location of a device
(say, /dev/vc/0) to the real location (/dev/tty0).
What really is the issue here is that devfs naming need not, and should
not, be made the standard just to achieve smooth upgrades for users of
devfs, which never even was the default Debian way of handling /dev.
* Andreas Metzler
> (I am not using it when booting 2.6, as it is obsolete and devfsd has not
> been updated).
* Darren Salt
> My impression is that it has, at least, been maintained. I think that
> it'll be retained as long as 2.6 is maintained, but removed completely
> in 2.7. (Of course, ICBW...)
No, it's unmaintained short of going through some aputations now and
then. From the latest kernel sources:
> Note that devfs has been obsoleted by udev,
> <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
> It has been stripped down to a bare minimum and is only provided for
> legacy installations that use its naming scheme which is
> unfortunately different from the names normal Linux installations
> use.
And yet, here we are trying to make the obsolete and "unfortunate"
naming scheme the default. An ill-advised decision if I ever saw one.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2004-03-06, 5:33 am |
| Tore Anderson <tore@debian.org> writes:
> * Tollef Fog Heen
>
>
> When I experimented with devfs and attempted to run without the symlinks
> my system broke down to the point of not booting fully, due to the fact
> that the devices where my system partitions was supposed to be located
> (/dev/hda1 and such) wasn't available any longer.
I didn't have that problem, though I didn't remove the compatibility
symlinks for just this reason.
> After having fixed that I just found that many other things was
> broken, such as for instance XMMS (due to the missing /dev/dsp and
> /dev/mixer), my floppy drive was inaccessible (no /dev/fd0 either),
> and so on for almost every piece of software using device nodes
> directly.
The vast majority of software in Debian should be devfs-aware already.
When I used it for a few months a few years ago I provided patches for
all the init scripts, config files, and so on that were broken on my
system, and all of them were included.
> Anyway, my complaint isn't that it will be technically impossible to
> build a system exclusively using non-standard device names, be it
> devfs names or something else entirely, but rather that this attempt to
> do so right now is undesireable and serves no good purpose.
> The current naming scheme is, after all, a universally accepted and
> ubiquitous standard, one which has been formalized by the Free Standards
> Group, and one which no major player in the GNU/Linux arena seem intent
> on changing in the foreseeable future. I believe we should have a very
> compelling rationale at the table before deciding to stray from it.
The current single directory with a bazillion device nodes in it
doesn't scale well. Not only is it difficult to find the nodes
actually available on your system, it also has the potential to hurt
performance. For example, an "ls /dev" on my system shows 1439 device
nodes, of which perhaps 10% are actually available and 5% have
actually ever been used. When any program scans /dev, that's 1400
dentries created for no good reason, and I haven't got the full set of
device nodes.
I do vastly prefer the devfs-style names, vc/1, tts/3 etc., and I use
these without devfs. The only aspects of devfs I disliked were:
/dev/cdroms }
/dev/discs } too unpredictable which device gets which number
/dev/ide0/lun0/.... far too unweildy when /dev/hda/3 would do as well
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-06, 6:33 am |
| Roger Leigh wrote:
> Tore Anderson <tore@debian.org> writes:
>
>
> I didn't have that problem, though I didn't remove the compatibility
> symlinks for just this reason.
>
>
> The vast majority of software in Debian should be devfs-aware already.
> When I used it for a few months a few years ago I provided patches for
> all the init scripts, config files, and so on that were broken on my
> system, and all of them were included.
>
>
>
> The current single directory with a bazillion device nodes in it
> doesn't scale well. Not only is it difficult to find the nodes
> actually available on your system, it also has the potential to hurt
> performance. For example, an "ls /dev" on my system shows 1439 device
> nodes, of which perhaps 10% are actually available and 5% have
> actually ever been used. When any program scans /dev, that's 1400
> dentries created for no good reason, and I haven't got the full set of
> device nodes.
However, that isn't a problem with udev, provided udev is operating
properly, because udev is supposed to *only* create device nodes for
devices which *exist*. So this issue does not really give any advantage to
devfs-style names.
> I do vastly prefer the devfs-style names, vc/1, tts/3 etc., and I use
> these without devfs. The only aspects of devfs I disliked were:
> /dev/cdroms }
> /dev/discs } too unpredictable which device gets which number
> /dev/ide0/lun0/.... far too unweildy when /dev/hda/3 would do as well
It's all very well to provide the devfs names (it doesn't hurt), but we
shouldn't be "moving away from" the traditional names, because the
traditional names are going to be standard, and devfs is basically
dying. :-(
--
Nathanael Nerode <neroden at gcc.gnu.org>
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/ http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-06, 6:33 am |
| Paul Hampson wrote:
<snip>
> I think the devfs naming scheme is better personally, as it gives you a
> structured view of what's in the system, and a structured way of dealing
> with devices... (IE v4l stuff lives in /dev/video, easy.)
>
> On the other hand, I can understand your point about not migrating away
> from the documented, standardised approach, (ugly as it may be :-)...
>
> The current default files create nodes in the devfs places, and symlink
> to the kernel names for the ide/scsi stuff. Maybe it ought to create
> nodes with the kernel names, and symlink to the devfs-style names?
That would be a rather nice default, actually. :-) My vote's for that.
--
Nathanael Nerode <neroden at gcc.gnu.org>
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/ http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tom Badran 2004-03-06, 6:33 am |
| On Saturday 06 Mar 2004 10:31, Nathanael Nerode wrote:
>
> That would be a rather nice default, actually. :-) My vote's for that.
My vote would be for the device nodes to be created in the correct place, and
then (decided via a debconf question) have devfs compatible symlinks created,
however these symlinks should be optional.
Tom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin Pitt 2004-03-06, 6:33 am |
| Hi!
> My vote would be for the device nodes to be created in the correct place,and
> then (decided via a debconf question) have devfs compatible symlinks created,
> however these symlinks should be optional.
IMHO this would result in a giant mess of flat and structured style
device names, as most devices would appear twice. debconf could rather
ask whether to create flat _or_ devfs-style names (for my sake also a
third option "both"). Of course this should also be a single
configuration option of udev (which defaults to the flat style).
I use devfs-only names (i. e. without compatibility symlinks) for a
long time now, including xmms (with alsa) and cdrecord. Everything
works fine with the devfs names, so it would be a pity to drop support
for it completely.
Thanks for considering and have a nice weekend!
Martin
--
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
| |
| Andreas Metzler 2004-03-06, 7:33 am |
| Roger Leigh <roger@whinlatter.uklinux.net> wrote:
[...]
> The current single directory with a bazillion device nodes in it
> doesn't scale well. Not only is it difficult to find the nodes
> actually available on your system, it also has the potential to hurt
> performance. For example, an "ls /dev" on my system shows 1439 device
> nodes, of which perhaps 10% are actually available and 5% have
> actually ever been used.
[...]
With udev you only have the device-nodes actually available on the
respective machine afaik.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tom Badran 2004-03-06, 7:33 am |
| On Saturday 06 Mar 2004 11:21, Martin Pitt wrote:
> Hi!
>
>
> IMHO this would result in a giant mess of flat and structured style
> device names, as most devices would appear twice. debconf could rather
> ask whether to create flat _or_ devfs-style names (for my sake also a
> third option "both"). Of course this should also be a single
> configuration option of udev (which defaults to the flat style).
Actually that does sound better ;)
> I use devfs-only names (i. e. without compatibility symlinks) for a
> long time now, including xmms (with alsa) and cdrecord. Everything
> works fine with the devfs names, so it would be a pity to drop support
> for it completely.
I really like a lot about the devfs naming scheme, especially the printers/X
and vc/X, however if the kernel guys say the old fashioned way is _proper_
then that is best to have as default. Ive also found very few difficulties in
using devfs style naming, although ive never used devfs on debian (caused all
sorts of hell with p-port zip drive a few years back) ive been using udev for
ages (well, about as long as i could) and really like it.
Tom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-03-06, 9:33 am |
| On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
> FWIW, I'm running udev on my laptop without problems (kernel 2.6.2), but I'm
> not running it on my desktop boxes. I plan to continue to use 2.4-series
> kernels on one of them, but I'd quite like to run 2.6.x+udev on the other;
> however, devfs it is for now because the DVB drivers don't yet support sysfs.
Maybe not, but they work fine with static device nodes (gasp!).
I don't think the script to create them is packaged, but it's in the
source for dvb-utils IIRC, called MAKEDEV.napi or similar.
I suppose static /dev is unfashionable yet surprisingly functional.
I never did see a reason to try devfs.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2004-03-06, 9:33 am |
| I demand that viro@parcelfarce.linux.theplanet.co.uk may or may not have
written...
> On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
[color=darkred]
> ... and a lot of people never allowed devfs on their boxen.
Which is fine, not a problem, their choice...
> "But I luurve devfs names" is not a reason to go against the standards and
> common practice alike.
I don't really see the relevance of that: there's no requirement to use its
different naming scheme if you're also running devfsd. (Though I do agree
with Roger Leigh about /dev/vc/* and similar, /dev/{cdroms,discs} and
/dev/ide*.)
"All of my devices' drivers support devfs, but not all support sysfs" _is_ a
good enough reason, IMO, given that I do want automatic creation of device
nodes. Since you appear to have ignored this point in my previous posting,
I'll just mention an example of this which I see here (the DVB drivers)
again...
> Make it a debconf question if you really want it; making it a default, let
> alone unconditional, has no excuses - standard compliance alone is enough
> to make that a bug.
AFAICS, the standards compliance is already there...
Hmm. This running for the hills... is it just me, or is there only one good
road to those hills? ;-)
--
| Darren Salt | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS | Toon Army | demon co uk
| We've got Shearer, you haven't
I am. Therefore, I think. I think.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-03-06, 10:33 am |
| On 06-Mar-04, 05:45 (CST), Tom Badran <tb100@doc.ic.ac.uk> wrote:
> I really like a lot about the devfs naming scheme, especially the printers/X
> and vc/X, however if the kernel guys say the old fashioned way is _proper_
> then that is best to have as default.
The "kernel guys" aren't saying that *anything* is "proper", which is
one of the points of udev. "Here's a device, call it what you want" is
their point-of-view.
Of course, there needs to be *some* default, and I think it would be
best to stick with the upstream udev default, especially if that's what
the other distributions are doing. As I understand it, it's trivial to
drop in alternative naming schemes, though, and shipping a "devfs" style
and others as examples with udev is good idea. There's no need for a
debconf question, though, as it will work fine out of the box, and one
can change simply by copying the example into place and rebooting.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2004-03-06, 10:33 am |
| I demand that Hamish Moffatt may or may not have written...
> On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
[color=darkred]
> Maybe not, but they work fine with static device nodes (gasp!).
Yes, but I'm trying to avoid that :-)
> I don't think the script to create them is packaged, but it's in the source
> for dvb-utils IIRC, called MAKEDEV.napi or similar.
Hmm. That looks like it should be a wishlist bug to me...
> I suppose static /dev is unfashionable yet surprisingly functional.
Could be... I have a minimal static /dev on my laptop "just in case".
> I never did see a reason to try devfs.
Well, each to his own :-)
--
| Darren Salt | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS | Toon Army | demon co uk
| Oh, sarge too...
An unbreakable toy is useful for breaking other toys.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| viro@parcelfarce.linux.theplanet.co.uk 2004-03-06, 10:33 am |
| On Sat, Mar 06, 2004 at 01:15:36PM +0000, Darren Salt wrote:
>
> I don't really see the relevance of that: there's no requirement to use its
> different naming scheme if you're also running devfsd. (Though I do agree
> with Roger Leigh about /dev/vc/* and similar, /dev/{cdroms,discs} and
> /dev/ide*.)
>
> "All of my devices' drivers support devfs, but not all support sysfs" _is_ a
> good enough reason, IMO, given that I do want automatic creation of device
> nodes. Since you appear to have ignored this point in my previous posting,
> I'll just mention an example of this which I see here (the DVB drivers)
> again...
Your problem; take that with DVB maintainers or submit patches yourself.
Let me put it that way:
1) both devfs and normal naming schemes must be supported - anything else
would break existing setups
2) normal scheme must be default, simply because it always had been default
on Linux; devfs' had been the optional one.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tore Anderson 2004-03-06, 11:33 am |
| * Steve Greenland
> The "kernel guys" aren't saying that *anything* is "proper",
You're wrong, see below.
> which is one of the points of udev. "Here's a device, call it what
> you want" is their point-of-view.
>
> Of course, there needs to be *some* default, and I think it would be
> best to stick with the upstream udev default, especially if that's what
> the other distributions are doing. As I understand it, it's trivial to
> drop in alternative naming schemes, though, and shipping a "devfs" style
> and others as examples with udev is good idea. There's no need for a
> debconf question, though, as it will work fine out of the box, and one
> can change simply by copying the example into place and rebooting.
I agree fully with you here, this is the way to go. Especially
considering that the "kernel guys" and the Free Standards Group/LANANA
indeed do mandate what's the "proper" default names, see:
1) http://www.lanana.org/docs/device-list/index.html
2) /usr/src/linux/Documentation/devices.txt
Of course, as you point out, udev makes it easy for an user to
override these defaults and adopt any naming scheme that he wish, be
it the devfs one or the Sun Solaris one. That's however none of our
business.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tom Badran 2004-03-06, 12:33 pm |
| On Saturday 06 Mar 2004 14:44, Steve Greenland wrote:
> On 06-Mar-04, 05:45 (CST), Tom Badran <tb100@doc.ic.ac.uk> wrote:
>
> The "kernel guys" aren't saying that *anything* is "proper", which is
> one of the points of udev. "Here's a device, call it what you want" is
> their point-of-view.
Sorry, must have misinterpreted it then, i got the impression from earlier
posts this was the case.
Tom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miles Bader 2004-03-08, 9:34 pm |
| Paul.Hampson@anu.edu.au (Paul Hampson) writes:
> I suspect the old-style naming config file would probably be a one
> line udev.rules: KERNEL="*" NAME="%k"
That works nicely for me (I just deleted the entire old udev.rules
file, and used that one line).
It has the advantage that it's:
(1) very, very, simple (and udev is -- generally -- pretty simple;
it would be nice to preserve that property in the default config)
(2) backward compatible
(3) conforms to current standards
I think it ought to be the default in the udev package; the much more
complicated devfs-style rules file can be included in the package as an
example people can drop in if they want.
If debian's going to move to a different naming scheme for /dev, it
seems like it should happen because a consensus of developer wants
too, not because a single developer happened to prefer it.
-Miles
--
`...the Soviet Union was sliding in to an economic collapse so comprehensive
that in the end its factories produced not goods but bads: finished products
less valuable than the raw materials they were made from.' [The Economist]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-08, 9:34 pm |
| On Mar 05, Tore Anderson <tore@debian.org> wrote:
As I'm not really interested in arguing over this, I will reply only to
a few of the comments.
> First of all, devfs is considered obsolete by the upstream kernel
> maintainers.
devfs is considered obsolete because nobody was willing to fix its
brokeness. I do not remember anybody declaring anything about the naming
style.
> I'll also wager that if we go with the devfs naming style we'll be the
> odd man out.
Well... this is the only argument I find compelling. Since millions of
flies cannot be wrong and I am not interested enough in the default
setting to fight this battle, I will switch udev to an almost-flat
naming scheme in one or two releases.
> The Linux kernel itself, and the upstream udev sources,
> names the devices the standardized (ttyS0) style and doesn't, as far as
The linux kernel does not dictate a naming policy. A big argument in
favour of udev (and against devfs) is that the device names should be
assigned by user space.
> I know, have -any- plans to change that. The same goes for Red Hat, and
> probably the most of the other major distributions. The only one I know
> of that's adopted devfs as the default is Gentoo, and according to their
> site they're about to ditch devfs (and I believe their udev package does
> the exact oposite of ours and creates compability symlinks for those
> already using the devfs names, and that they mean to get rid of it
> completely after their users have had some transitioning time).
You can easily check the udev.rules.gentoo file and see for yourself
that gentoo is still committed to a devfs-like naming scheme.
> What really is the issue here is that devfs naming need not, and should
> not, be made the standard just to achieve smooth upgrades for users of
> devfs, which never even was the default Debian way of handling /dev.
I never intended to do this. I consider the devfs naming style superior
on its own merits.
Tollef Fog Heen:
>I think you are overestimating the problems. I used to run without
>any compat symlinks, just devfs, and apart from the fact that you have
>to fix inittab, it mostly Just Worked.
This has been my experience as well. Almost all of our packages support
devfs names anyway. You obviously have to use the correct devices in
fstab and inittab if you choose to disable compatibility symlinks.
Steve Greenland:
>There's no need for a
>debconf question, though, as it will work fine out of the box, and one
>can change simply by copying the example into place and rebooting.
Agreed. I'm not going to use debconf unless it will be necessary.
Claus Färber quoted FHS and the LANANA registry. The first has not
mandated any naming style since version 2.2 (almost three years old),
while the second has obviously never been normative for devices names
as devfs implemented a different scheme.
--
ciao, |
Marco | [4985 sp0k0qkcFh13U]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| A Mennucc 2004-03-09, 5:33 am |
| Martin Pitt wrote:
>IMHO this would result in a giant mess of flat and structured style
>device names, as most devices would appear twice. debconf could rather
>ask whether to create flat _or_ devfs-style names (for my sake also a
>third option "both"). Of course this should also be a single
>configuration option of udev (which defaults to the flat style).
>
>
>
I vote for this too. FLAT or STRUCTURED or BOTH
in a nice debconf question
and we should also not forget the non-i386 world
I seem to remember that some big architectures need a structured /dev
(since they have far too many devices... a flat structure is unintelligible)
>I use devfs-only names
>
>
debian-installer uses them at well
we don't want to cripple debian-installer before it is even finished, do we?
a.
--
all of the above UTMBK
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-03-09, 5:33 am |
| On Tue, Mar 09, 2004 at 01:38:41AM +0100, Marco d'Itri wrote:
> On Mar 05, Tore Anderson <tore@debian.org> wrote:
>
> As I'm not really interested in arguing over this, I will reply only to
> a few of the comments.
>
> devfs is considered obsolete because nobody was willing to fix its
> brokeness. I do not remember anybody declaring anything about the naming
> style.
According to Greg K-H devfs naming violates LSB... Actually it seems to
violate FHS prior to 2.3, which is what is specified to be used by LSB
1.3/1.9.6. Since Debian attempts to adhere to the FHS/LSB it probably
should follow those guidelines ;). Even using devfs with compat layer
is a violation of FHS 2.2 from what I can tell... Once FHS 2.3 is
accepted by the LSB Debian can rename the devices as they wish.
http://www.kernel.org/pub/linux/uti...g/udev_vs_devfs
Note: That is the on the same site you download the source off of. ;)
---
FHS 2.2
6.1.3 /dev : Devices and special files
All devices and special files in /dev should adhere to the Linux Allocated
Devices document, which is available with the Linux kernel source. It is
maintained by H. Peter Anvin <address omitted>.
Symbolic links in /dev should not be distributed with Linux systems except
as provided in the Linux Allocated Devices document.
BEGIN RATIONALE
The requirement not to make symlinks promiscuously is made because local
setups will often differ from that on the distributor's development
machine. Also, if a distribution install script configures the symbolic
links at install time, these symlinks will often not get updated if local
changes are made in hardware. When used responsibly at a local level,
however, they can be put to good use.
END RATIONALE
---
FHS 2.3
/dev : Devices and special files
The following devices must exist under /dev.
/dev/null
All data written to this device is discarded. A read from this device will
return an EOF condition.
/dev/zero
This device is a source of zeroed out data. All data written to this
device is discarded. A read from this device will return as many bytes
containing the value zero as was requested.
/dev/tty
This device is a synonym for the controlling terminal of a process. Once
this device is opened, all reads and writes will behave as if the actual
controlling terminal device had been opened.
Rationale
Previous versions of the FHS had stricter requirements for /dev. Other
devices may also exist in /dev. Device names may exist as symbolic links
to other device nodes located in /dev or subdirectories of /dev. There
is no requirement concerning major/minor number values.
---
LSB 1.3
Chapter 20. File System Hierarchy
An LSB conforming implementation must adhere to the FHS 2.2.
---
LSB 1.95
Chapter 4. File System Hierarchy
An LSB conforming implementation shall adhere to the FHS 2.2.
---
| |
| Tore Anderson 2004-03-09, 5:35 pm |
| * Marco d'Itri
> Since millions of flies cannot be wrong and I am not interested
> enough in the default setting to fight this battle, I will switch
> udev to an almost-flat naming scheme in one or two releases.
Thank you. I firmly believe that it is the right thing to do.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| Tollef Fog Heen <tfheen@raw.no> writes:
> * Tore Anderson
>
> | That one of our goals shall be to eventually have changed all of our
> | packages to use the devfs-style naming style exclusively and have removed
> | the symlinks from the standard locations, thus having rendered ourselves
> | incompatible with every other major distributor (and that includes most
> | upstream sources that use device nodes directly), is absolutely
> | ludicrous. Not only is it a unrealistic goal, but I fail to see *any*
> | advantage accomplishing it will make.
Sarge is using devfs in its installer and its been used widely for a
long time now. I myself have been using devfs _without_devfsd_ since
the first 2.4 test kernels and found (and patched a few) very few
programms that won't work. There is hardly anything that uses device
nodes directly and I know of no case where it makes sense to limit the
source to a single device. Any software that has no option to change
e.g. the dsp device to be used is just plain buggy.
> I think you are overestimating the problems. I used to run without
> any compat symlinks, just devfs, and apart from the fact that you have
> to fix inittab, it mostly Just Worked.
I submitted a patch for init and getty to transparently translate
between devfs and non devfs names over a year ago so even that little
anoyance could be easily delt with.
So I'm all for sticking with maintaining devfs names. The only thing
obsolete in devfs is the suposedly race codition riddled code. The
nameing scheme is way better and more orderly than the obsolete flat
/dev structure.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| Tore Anderson <tore@debian.org> writes:
> * Tollef Fog Heen
>
>
> When I experimented with devfs and attempted to run without the symlinks
> my system broke down to the point of not booting fully, due to the fact
> that the devices where my system partitions was supposed to be located
> (/dev/hda1 and such) wasn't available any longer. After having fixed
inittab and fstab need change, freshly installed systems would get that
automatically.
For updates the udev package could check for the existing naming
scheme and keep using that.
> that I just found that many other things was broken, such as for instance
> XMMS (due to the missing /dev/dsp and /dev/mixer), my floppy drive
xmms -> configure -> options -> preference
Output plugin -> configure -> use alternate device
Same procedure as getting xxms to use the 2nd soundcard.
> was inaccessible (no /dev/fd0 either), and so on for almost every piece
/etc/mtools.conf
> of software using device nodes directly. It surprises me to hear that
> you didn't run into such problems, but then again, I did my testing for
> quite some time ago - things may have changed since then.
Its all just a little bit of configuring. Most software gets it right
on its own, some needs some help. The only software that I use that
has a problem is vmware and guess why its not fixed already.
> Anyway, my complaint isn't that it will be technically impossible to
> build a system exclusively using non-standard device names, be it
> devfs names or something else entirely, but rather that this attempt to
> do so right now is undesireable and serves no good purpose.
Its way over due to change it. If your using a debian kernel check
/proc/partitions and wonder about the strange names there. Quite some
software is getting confused by that. So the world with old names is
not all nice and shiny.
> The current naming scheme is, after all, a universally accepted and
> ubiquitous standard, one which has been formalized by the Free Standards
> Group, and one which no major player in the GNU/Linux arena seem intent
> on changing in the foreseeable future. I believe we should have a very
> compelling rationale at the table before deciding to stray from it.
Then Debian has to be one of the distributions imrpoving it. 
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| A Mennucc <mennucc1@debian.org> writes:
> Martin Pitt wrote:
>
>
> I vote for this too. FLAT or STRUCTURED or BOTH
> in a nice debconf question
>
> and we should also not forget the non-i386 world
> I seem to remember that some big architectures need a structured /dev
> (since they have far too many devices... a flat structure is unintelligible)
Ever used "dd if=/dev/<tab>"? With the devfs name thats no problem at
all since there are only so few devices in the top level (or each
subdir). Even on i386 its insane to do that with the old flat way.
As for even more probelmatic archs: E.g. (iirc) S390 can have 65536
harddisks with 65536 partitions. Have fun making up flat names for
them.
>
> debian-installer uses them at well
>
> we don't want to cripple debian-installer before it is even finished, do we?
Well, to be fair, D-I could boot with a devfs style udev config, just
like its using devfs now, while still installing a flat config in
/target (again like now).
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| Roger Leigh <roger@whinlatter.uklinux.net> writes:
> The current single directory with a bazillion device nodes in it
> doesn't scale well. Not only is it difficult to find the nodes
> actually available on your system, it also has the potential to hurt
> performance. For example, an "ls /dev" on my system shows 1439 device
> nodes, of which perhaps 10% are actually available and 5% have
> actually ever been used. When any program scans /dev, that's 1400
> dentries created for no good reason, and I haven't got the full set of
> device nodes.
With udev you would only get those 10% actually available. No hda60 if
you only have 5 partitions on hda. But still the /dev would be pages
full on reasonable systems.
> I do vastly prefer the devfs-style names, vc/1, tts/3 etc., and I use
> these without devfs. The only aspects of devfs I disliked were:
> /dev/cdroms }
> /dev/discs } too unpredictable which device gets which number
Just like /dev/scd0 or /dev/sda, /dev/dsp. Its just hdXY that
specifies a specific hardware port and even that chages if you have
two ide controlers and the order the modules/drivers get loaded
changes. Pretty much everything else is very dynamic already.
> /dev/ide0/lun0/.... far too unweildy when /dev/hda/3 would do as well
/dev/ide/host0/bus0/target0/lun0/disc
/dev/scsi/host0/bus0/target1/lun0/disc
Some subdirs could be omitted. Like lun0 on ide since ide has no luns.
But having a tree structure following the hardware starting with the
type, the controler, the connector, the id of the drive and last the
lun is a very clean way to address all hardware. Many scsi cd changers
use the lun to select the CD to use for example. For systems with a
lot of hardware thats very organised.
For systems with less hardware the /dev/discs/ links should be unique
enough to be usefull. E.g. on my laptop I use /dev/discs since it only
has one harddisk. No chance of confusion there. Same for /dev/cdrom,
all my systems have 0 or 1 cdrom drive.
What bothers me is that the /dev/discs/ links get resolved and show up
as the long names they point to. That looks ugly in the mount or df
output and is a bit confusing when comparing the fstab to mount/df
output. Maybe instead of linking real devices should be setup. That
way whatever device is used will show up in programs output.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| Andreas Metzler <ametzler@downhill.at.eu.org> writes:
> Tore Anderson <tore@debian.org> wrote:
>
> [...]
>
> I think Tore has made a pretty strong case already I would like to
> hear an answer to a simple "Why?" by Marco.
I think the "Why devfs style" can be answered in one sentence:
People trying it out are the same people that tried out / use devfs.
> One of the major obstacles that kept devfs from being adopted by a
> wider audience (besides the racing conditions) was its default naming
> scheme, duplicating this in udev does not look advisable to me.
People are always against change. The only way is to get everybody new
used to the new way and build up enough peer pressure to change the
old guys.
> This is nothing personal, I have been using devfs since I switched to
> 2.4 (I am not using it when booting 2.6, as it is obsolete and devfsd
> has not been updated).
> cu andreas
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:33 pm |
| Hamish Moffatt <hamish@debian.org> writes:
> On Fri, Mar 05, 2004 at 08:20:53PM +0000, Darren Salt wrote:
>
> Maybe not, but they work fine with static device nodes (gasp!).
> I don't think the script to create them is packaged, but it's in the
> source for dvb-utils IIRC, called MAKEDEV.napi or similar.
>
> I suppose static /dev is unfashionable yet surprisingly functional.
> I never did see a reason to try devfs.
1. Read only / systems need /dev in a ramdisk or devfs. That means
either wasting ram on a huge /dev or selectivly only putting needed
device nodes into /dev. Having the kernel mount devfs on boot (or via
fstab) is just way simpler.
2. usb device need dynamic nodes
3. only available device node, less clutter
4. structured layout, easy to find devices or to use tab completion
The first 3 apply to udev in general too, the last only to a devfs
style config.
MfG
Goswin
PS: also with devfs scsi devices are at fixed positions and don't
change their name depending on what scsi devices (like external cd
burner) are on or off currently.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-03-27, 10:34 pm |
| Paul.Hampson@anu.edu.au (Paul Hampson) writes:
> On Fri, Mar 05, 2004 at 10:19:05AM -0600, Chad Walstrom wrote:
>
> Maybe it ought to look at the current /dev layout? That'd save a
> question that's easily guessable. On the other hand, automating such a
> choice (which I was considering suggesting as well) leads to hassles
> in the conf-file handling, as something has to cease being a conffile.
>
> A notification of some kind if devfs is detected for the user to install
> the devfs configuration example file (yes, all kinds of assumptions in
> that sentence) would be sufficient, since udev does _not_ start at the
> end of postinst, so it's not too late. :-)
Its trivial to preset the debconf question to an autodetect value and
to set the question priority so it normally doesn't get asked.
Control freaks will get the question and 'normal' people can
reconfigure the question if they are not satisfied with the default.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miles Bader 2004-03-31, 10:34 pm |
| Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> So I'm all for sticking with maintaining devfs names.
And I'm all against it. (Whee!)
> The only thing obsolete in devfs is the suposedly race codition
> riddled code. The nameing scheme is way better and more orderly than
> the obsolete flat /dev structure.
Well, it's nice that you've expressed your opinion, but if debian's dev
naming scheme is to be changed, then it should be done as the result of
a concensus to make that change, not because a particular maintainer
happened to like it better.
Using udev does remove the most annoying thing about the traditional
naming scheme on a typical workstation, the enormous gobs of unused
names; here's my /dev for instance, which seems quite reasonable to me:
MAKEDEV@ fd@ hdc mice pts/ tty tty6 xconsole|
agpgart fd0 initctl| mouse0 random tty0 tty7 zero
apm_bios full kmem null shm/ tty1 tty8
console hda kmsg port sndstat@ tty2 tty9
core@ hda1 log= ppp stderr@ tty3 ttyS0
event0 hda2 loop0 psaux stdin@ tty4 ttyS1
event1 hda3 mem ptmx stdout@ tty5 urandom
created with this /etc/udev/udev.rules file (and all other .rules files
in /etc/udev deleted):
KERNEL="ttyS[2-9]"
KERNEL="tty[1-9][0-9]"
#default: KERNEL="*", NAME="%k"
-Miles
--
We live, as we dream -- alone....
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-04-01, 4:38 pm |
| Miles Bader <miles@lsi.nec.co.jp> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
> And I'm all against it. (Whee!)
Thats makes 1:1. Lets get more people to get a quorum.
>
> Well, it's nice that you've expressed your opinion, but if debian's dev
> naming scheme is to be changed, then it should be done as the result of
> a concensus to make that change, not because a particular maintainer
> happened to like it better.
Currently using udev is your choice. And its the maintainers choice
how to package it up. As seen with for example ifupdown, if the
maintainer is not willing to change a package your out of luck.
It should be done by forming a concensus and the maintainer following
that but saddly enough thats not what happens in Debian. Luckily the
udev maintainer is open for suggestions and discussions.
> Using udev does remove the most annoying thing about the traditional
> naming scheme on a typical workstation, the enormous gobs of unused
> names; here's my /dev for instance, which seems quite reasonable to me:
>
> MAKEDEV@ fd@ hdc mice pts/ tty tty6 xconsole|
> agpgart fd0 initctl| mouse0 random tty0 tty7 zero
> apm_bios full kmem null shm/ tty1 tty8
> console hda kmsg port sndstat@ tty2 tty9
> core@ hda1 log= ppp stderr@ tty3 ttyS0
> event0 hda2 loop0 psaux stdin@ tty4 ttyS1
> event1 hda3 mem ptmx stdout@ tty5 urandom
Hmm, I'm missing a few things but that is probably your kernel config:
No /dev/rtc? You realy have no realtime clock support?
How does loop0 come about? Is that in use or did you limit the number
of loop devices in the kernel to 1?
No ramdisk support?
> created with this /etc/udev/udev.rules file (and all other .rules files
> in /etc/udev deleted):
>
> KERNEL="ttyS[2-9]"
> KERNEL="tty[1-9][0-9]"
> #default: KERNEL="*", NAME="%k"
Which leaves the problem of varying device nodes for hardware.
This can be a security issue: The cleaning lady pulled the plug on an
external drive, the system reboots and suddenly the zipdrive is
mounted as /usr giving instant root access trough a
/usr/bin/root-shell setuid.
Or cause data loss: The harddisk with /tmp doesn't spin up on reboot
and the next one, where /home is, is used instead. Enjoy tmp being
cleaned.
Or is just anoying because you can't see what device is which drive
unless you have the early boot messages still around.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2004-04-01, 4:39 pm |
| On Thu, Apr 01, 2004 at 11:11:05PM +0200, Goswin von Brederlow wrote:
> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>
> Thats makes 1:1. Lets get more people to get a quorum.
okay, fwiw, i'm against devfs names in as much as i don't think they are
what should be used by default. if there's a low or medium priority
debconf question that gives the option between one and/or the other,
all the better, but at least by default let's do things like the rest
of the linux/unix world please
sean
| |
| Steve Greenland 2004-04-01, 5:35 pm |
| On 01-Apr-04, 15:11 (CST), Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>
> Thats makes 1:1. Lets get more people to get a quorum.
Oh, cripes, lets not again. Read the rest of this thread. The default,
as determined by the package maintainer after feedback, is the
traditional flat /dev layout, as used by pretty much every other
distribution out there (yes, I know there are exceptions, please don't
bother to list them.)
If you don't like the default, then change it on your machine. Why is
this such a big deal? Why is that so many people around here get so
upset if they don't get their way on something that is so easily changed
to match their personal preference?
Clearly, the flat layout works. The major semi-technical objection to it
("too may entries") is solved by udev.
Clearly, the devfs layout works too.
Therefore, the maintainer should pick one or the other. I *personally*
think that avoiding gratuitous differences from other distros and
previous releases of Debian tend to drive towards the flat layout, but
if the maintainer decides otherwise, then okay, that will something I
have to change on the systems I care about, if I care enough. It's less
effort that replacing exim with postfix, so no big deal.
OTOH, I'd object strongly to adding a debconf question about this. The
vast majority of the people installing either a) won't understand the
question, or b) don't give a shit, they just stuff to work. Inflicting
internal political battles on our users is a bad idea.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-04-01, 6:34 pm |
| sean finney <seanius@seanius.net> writes:
> On Thu, Apr 01, 2004 at 11:11:05PM +0200, Goswin von Brederlow wrote:
>
> okay, fwiw, i'm against devfs names in as much as i don't think they are
> what should be used by default. if there's a low or medium priority
> debconf question that gives the option between one and/or the other,
> all the better, but at least by default let's do things like the rest
> of the linux/unix world please
Why not default to the scheme thats in place?
People with devfs would get devfs style, people without (or fresh
installs) would get flat old style and people with debconf priority
medium/low would see the question with that default (others just
get the default).
Its not that hard to guess the style used already by the user.
if [ -e /dev/.devfsd ]; then
# devfs
if [ -e /dev/tty0 ]; then
# linked or manually created, e.g. devfsd, default to flat?
else
# no devfsd, devfs style needed
fi
else
# flat
fi
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-04-01, 6:34 pm |
| Steve Greenland <steveg@moregruel.net> writes:
> On 01-Apr-04, 15:11 (CST), Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>
> Oh, cripes, lets not again. Read the rest of this thread. The default,
> as determined by the package maintainer after feedback, is the
> traditional flat /dev layout, as used by pretty much every other
> distribution out there (yes, I know there are exceptions, please don't
> bother to list them.)
>
> If you don't like the default, then change it on your machine. Why is
> this such a big deal? Why is that so many people around here get so
> upset if they don't get their way on something that is so easily changed
> to match their personal preference?
Because I (and many other users updating) won't be able to boot
anymore if I miss that sudden change (and for other lesser reasons).
> Clearly, the flat layout works. The major semi-technical objection to it
> ("too may entries") is solved by udev.
>
> Clearly, the devfs layout works too.
>
> Therefore, the maintainer should pick one or the other. I *personally*
Or pick both and decide at install time which one is appropiate. Would
it be so hard to support both systems?
I'm not saying devfs style should be default per se. _Personally_ I
would prefer having devfs on new systems but thats beside the
point. What I have a problem with is breaking existing systems. Its
easy to support both kinds so why not do that and make everyone happy?
> think that avoiding gratuitous differences from other distros and
> previous releases of Debian tend to drive towards the flat layout, but
> if the maintainer decides otherwise, then okay, that will something I
> have to change on the systems I care about, if I care enough. It's less
> effort that replacing exim with postfix, so no big deal.
>
> OTOH, I'd object strongly to adding a debconf question about this. The
> vast majority of the people installing either a) won't understand the
> question, or b) don't give a shit, they just stuff to work. Inflicting
> internal political battles on our users is a bad idea.
Low priority question. I agree that this should not come up on a nomal
installation. But having it available as question is nice.
> Steve
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christoph Hellwig 2004-04-02, 1:34 am |
| On Fri, Apr 02, 2004 at 01:23:48AM +0200, Goswin von Brederlow wrote:
>
> Because I (and many other users updating) won't be able to boot
> anymore if I miss that sudden change (and for other lesser reasons).
So you suddenly remove devfs from your kernel config and complain if you
didn't setup udev properly? If you really epected that to work I'd call
you a fool. Else stop trolling.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2004-04-02, 1:34 am |
| >>>>> "Goswin" == Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
Goswin> Why not default to the scheme thats in place? People with
Goswin> devfs would get devfs style, people without (or fresh
Goswin> installs) would get flat old style and people with debconf
Goswin> priority medium/low would see the question with that
Goswin> default (others just get the default).
Just make it easy to change after installation...
You might want devfs names even though devfs isn't installed yet (as
it isn't the default).
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roger Leigh 2004-04-02, 5:37 am |
| sean finney <seanius@seanius.net> writes:
> On Thu, Apr 01, 2004 at 11:11:05PM +0200, Goswin von Brederlow wrote:
>
> okay, fwiw, i'm against devfs names in as much as i don't think they are
> what should be used by default. if there's a low or medium priority
> debconf question that gives the option between one and/or the other,
> all the better, but at least by default let's do things like the rest
> of the linux/unix world please
Many/most commercial Unixen have had devfs-like systems for years ;-).
--
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Theodore Ts'o 2004-04-02, 9:34 am |
| Package: udev
Version: 0.022-1
Severity: serious
On Thu, Apr 01, 2004 at 04:07:22PM -0600, Steve Greenland wrote:
> Oh, cripes, lets not again. Read the rest of this thread. The default,
> as determined by the package maintainer after feedback, is the
> traditional flat /dev layout, as used by pretty much every other
> distribution out there (yes, I know there are exceptions, please don't
> bother to list them.)
Let me point out that Debian Policy (as well as the Linux Standard
Base, which many other distributions are certified against), requires
the Filesystem Hierarchy Standard, and quoting from
/usr/share/doc/debian-policy/fhs/fhs.txt.gz:
6.1.2 /dev : Devices and special files
All devices and special files in /dev should adhere to the Linux
Allocated Devices document, which is available with the Linux kernel
source. It is maintained by H. Peter Anvin <hpa@zytor.com>.
This can be found here:
http://www.lanana.org/docs/device-list/devices.txt
..... and you can see that it specifies the flat namespace.
And in case people think that the "should" means that it is
option, let me quote from section 1.8, Conformance, of the above FHS
specification:
The terms "must", "should", "contains", "is" and so forth should be read
as requirements for compliance or compatibility.
Unlike other documents, such as RFC's, for the purposes of at least
this version of the FHS, which is the one mandated by Debian Policy,
"must" == "should".
Hence, the udev package, as currently configured by default, violates
Debian policy, and as such, this is a release-critical bug which
**MUST** be fixed.
- Ted
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-04-02, 10:38 am |
| On Fri, Apr 02, 2004 at 08:47:09AM -0500, Theodore Ts'o wrote:
> Package: udev
> Version: 0.022-1
> Severity: serious
(Please use X-Debbugs-Cc: so that those of us reading via debian-devel
get the bug number.)
> On Thu, Apr 01, 2004 at 04:07:22PM -0600, Steve Greenland wrote:
^^^^^^[color=darkred]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^[color=darkr
ed]
>
> Let me point out that Debian Policy (as well as the Linux Standard
> Base, which many other distributions are certified against), requires
> the Filesystem Hierarchy Standard, and quoting from
> /usr/share/doc/debian-policy/fhs/fhs.txt.gz:
>
> 6.1.2 /dev : Devices and special files
>
> All devices and special files in /dev should adhere to the Linux
> Allocated Devices document, which is available with the Linux kernel
> source. It is maintained by H. Peter Anvin <hpa@zytor.com>.
>
> This can be found here:
>
> http://www.lanana.org/docs/device-list/devices.txt
>
> .... and you can see that it specifies the flat namespace.
[...]
> Hence, the udev package, as currently configured by default, violates
> Debian policy, and as such, this is a release-critical bug which
> **MUST** be fixed.
Huh? As noted above, udev *does* use the flat namespace.
udev (0.022-1) unstable; urgency=medium
[...]
* Switched the default /dev layout to traditional style.
(Closes: #237482, #237484)
[...]
-- Marco d'Itri <md@linux.it> Sun, 21 Mar 2004 13:31:02 +0100
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-04-02, 11:37 am |
| On Apr 02, Steve Greenland <steveg@moregruel.net> wrote:
> Clearly, the flat layout works. The major semi-technical objection to it
> ("too may entries") is solved by udev.
No. The major technical objection to the old-style layout is that
non-positional names like sdX and hdX are a PITA for non-trivial systems
because drives may change name when new ones are plugged in.
> Therefore, the maintainer should pick one or the other. I *personally*
> think that avoiding gratuitous differences from other distros and
> previous releases of Debian tend to drive towards the flat layout, but
This is the reason in the end I choose to use the old-style layout, but
after doing this I noticed that the red hat package uses a
devfs-style-with-symlinks layout.
Anyay, udev will stay old-style for the next future, the default can be
changed at any time.
> OTOH, I'd object strongly to adding a debconf question about this. The
Me too, I have no plan to do it.
--
ciao, |
Marco | [5530 prcmR4La0eiSo]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Theodore Ts'o 2004-04-02, 1:37 pm |
| On Fri, Apr 02, 2004 at 04:13:26PM +0100, Colin Watson wrote:
> Huh? As noted above, udev *does* use the flat namespace.
>
> udev (0.022-1) unstable; urgency=medium
>
> [...]
> * Switched the default /dev layout to traditional style.
> (Closes: #237482, #237484)
> [...]
My bad. I missed this in the latest release. I had spent a bunch of
time hand-hacking the config files to use the traditional style, and
didn't notice that the default config files had changed back.
My apologies, I should have looked more carefully.
- Ted
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Theodore Ts'o 2004-04-02, 1:37 pm |
| On Fri, Apr 02, 2004 at 05:42:32PM +0200, Marco d'Itri wrote:
> On Apr 02, Steve Greenland <steveg@moregruel.net> wrote:
>
>
> No. The major technical objection to the old-style layout is that
> non-positional names like sdX and hdX are a PITA for non-trivial systems
> because drives may change name when new ones are plugged in.
That particular "major technical objection" is solved by using LABEL=
and UUID= in /etc/fstab.
- Ted
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2004-04-02, 1:37 pm |
| On 01-Apr-04, 16:35 (CST), Roger Leigh <roger@whinlatter.uklinux.net> wrote:
>
> Many/most commercial Unixen have had devfs-like systems for years ;-).
>
Perhaps those whose name begins with "Sol". OTOH, AIX 5 still seems to
be flat.
In any case, it's irrelevant. We are a Linux distribution (or, at least,
we are, at present, considering the Debian GNU/Linux distribution). We
should match that.
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-04-02, 5:34 pm |
| Theodore Ts'o <tytso@mit.edu> writes:
> On Fri, Apr 02, 2004 at 05:42:32PM +0200, Marco d'Itri wrote:
>
> That particular "major technical objection" is solved by using LABEL=
> and UUID= in /etc/fstab.
Won't work for cdroms, partition formats without UUID,
filesystems without label .... but lets ignore those for a moment.
If you use this argument you should be in support of using LABEL= or
UUID= when creating the fstab in the Debian-Installer, right?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-04-02, 6:37 pm |
| On Apr 02, Theodore Ts'o <tytso@mit.edu> wrote:
>
> That particular "major technical objection" is solved by using LABEL=
> and UUID= in /etc/fstab.
Only for file systems which support this, and only for when they can be
referenced by fstab. Swap partitions are a common example of why this is
not enough.
--
ciao, |
Marco | [5532 acUmGKsy913Xg]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Theodore Ts'o 2004-04-02, 6:37 pm |
| On Sat, Apr 03, 2004 at 12:00:48AM +0200, Goswin von Brederlow wrote:
>
> Won't work for cdroms, partition formats without UUID,
> filesystems without label .... but lets ignore those for a moment.
>
(1) Removeable medias have their own problem since what's important is
generally not *which* CD-ROM player/drive, but *which* CD-ROM has been
inserted, regardless of which drive the CD-ROM happened to be inserted
into.
(2) ISO 9660 and do have label support. Mount doesn't support it yet,
but there are patches that convert it to use the blkid library, and it
woudln't be that hard to add label support for CD-ROM's. This would
actually be far more useful, since we could now mount the CD-ROM in a
different location based on the contents of the CD-ROM, rather than
based on the CD-ROM's SCSI id or position in the SCSI chain, both of
which are equally wrong, although simpler.
(3) Most filesystems have UUID's and/or Labels at this point.
> If you use this argument you should be in support of using LABEL= or
> UUID= when creating the fstab in the Debian-Installer, right?
Correct, I would be in favor of doing this, since it correctly solves
the problem even if the SCSI id of the device changes. This will
become even more important if people are using devices that are based
on Firewire or USB, where the SCSI id is even more subject to change,
and therefore just as useless as "/dev/sda". You really should be
mounting based on filesystem UUID or Label.
- Ted
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gunnar Wolf 2004-04-02, 7:33 pm |
| Goswin von Brederlow dijo [Thu, Apr 01, 2004 at 11:11:05PM +0200]:
>
> Thats makes 1:1. Lets get more people to get a quorum.
> (...)
>
> Currently using udev is your choice. And its the maintainers choice
> how to package it up. As seen with for example ifupdown, if the
> maintainer is not willing to change a package your out of luck.
>
> It should be done by forming a concensus and the maintainer following
> that but saddly enough thats not what happens in Debian. Luckily the
> udev maintainer is open for suggestions and discussions.
Fortunately, what usually happens in Debian is that that given
maintainer will listen to what the others have to say, if they have
anything to say at all. I hope this will be the case as well - I see
that udev will start becoming popular, and probably most users will
end up living with it. I don't think it is too far fetched to think
sarge+1 will have udev as part of the base system. For such a
component, I think reaching a consensus -maybe even getting it to the
policy- is needed. Too many packages will depend on the location of
some device files, as was mentioned previously in this discussion.
Greetings,
--
Gunnar Wolf - gwolf@gwolf.cx - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Junichi Uekawa 2004-04-02, 7:34 pm |
| > > Many/most commercial Unixen have had devfs-like systems for years ;-).
>
> Perhaps those whose name begins with "Sol". OTOH, AIX 5 still seems to
> be flat.
Hmm? I thought "sol*" had hierarchy like
/dev/dsk/c*
which is only one hierarchy, not like devfs.
I personally like the scsidev approach.
regards,
junichi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Theodore Ts'o 2004-04-02, 8:33 pm |
| On Fri, Apr 02, 2004 at 05:16:00PM -0600, Gunnar Wolf wrote:
> Fortunately, what usually happens in Debian is that that given
> maintainer will listen to what the others have to say, if they have
> anything to say at all. I hope this will be the case as well - I see
> that udev will start becoming popular, and probably most users will
> end up living with it. I don't think it is too far fetched to think
> sarge+1 will have udev as part of the base system. For such a
> component, I think reaching a consensus -maybe even getting it to the
> policy- is needed.
As I've already said, Debian Policy requires the FHS, and quoting from
/usr/share/doc/debian-policy/fhs/fhs.txt.gz:
1.8 Conformance with this Document
...
The terms "must", "should", "contains", "is" and so forth should be read
as requirements for compliance or compatibility.
6.1.2 /dev : Devices and special files
All devices and special files in /dev should adhere to the Linux
Allocated Devices document, which is available with the Linux kernel
source. It is maintained by H. Peter Anvin <hpa@zytor.com>.
This document is located here, and specifies the flat namespace:
http://www.lanana.org/docs/device-list/devices.txt
Hence, the flat namespace is already mandated b | | |