> So, how does devfs stack up to the above problems and constraints:
> Problems:
> 1) devfs only shows the dev entries for the devices in the system.
Is this a problem? Where exactly this problem lies?
> 2) devfs does not handle the need for dynamic major/minor numbers
Neither does udev. Both take whatever driver gives them.
> 3) devfs does not provide a way to name devices in a persistent
> fashion.
I am not sure what exactly you mean here.
> 4) devfs does provide a deamon that userspace programs can hook > into
> to listen to see what devices are being created or removed.
> Constraints:
> 1) devfs forces the devfs naming policy into the kernel. If you
> don't like this naming scheme, tough.
kernel imposes naming scheme for exporting devices in sysfs. It is
possible to get rid of devfs_name in kernel and use those names
that must exist anyway to support udev as well. devfs has
devfsd that can call whatever naming agent you like.
> 2) devfs does not follow the LSB device naming standard.
it is user-space (devfsd) issue, not kernel space (devfs)
> 3) devfs is small, and embedded devices use it. However it is
> implemented in non-pagable memory.
Same for sysfs. Other Unices have pageable kernel memory. If Linux
had it any memory based filesystem could benefit from it. I did not
look at backing store for sysfs patches but it is likely that same
idea could be used for devfs.
> Oh yeah, and there are the insolvable race conditions with the devfs
> implementation in the kernel, but I'm not going to talk about them > right
I do not argue that current devfs implementation is ugly and racy. I
just beg you to point at what makes those races "unsolvable".
> now, sorry. See the linux-kernel archives if you care about them (and
> if you use devfs, you should care...)
I do care. Searching archives for devfs mostly brings "everyone knows
this is crap". That is why I kindly ask you to show real evidence that
the problems it has are unsolvable.
> So devfs is 2 for 7, ignoring the kernel races.
Hmm ... I really see only one - devfs names that are historically
used. Assuming that
- devfs just exports kernel names (that must exist anyway)
- sysfs provides consistent cdev view as it does for bdev
devfsd simply can take kernel name and call whatever program you like
to implement naming policy including udev. With added benefit of
removable devices support :)
regards
-andrey
On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
>
> > 4) devfs does provide a deamon that userspace programs can hook > into
> > to listen to see what devices are being created or removed.
> > Constraints:
> > 1) devfs forces the devfs naming policy into the kernel. If you
> > don't like this naming scheme, tough.
>
> kernel imposes naming scheme for exporting devices in sysfs. It is
> possible to get rid of devfs_name in kernel and use those names
> that must exist anyway to support udev as well. devfs has
> devfsd that can call whatever naming agent you like.
Yes. I'm having trouble finding justification for that statement as
well.
devfs appears to have almost no device name info within it.
>
> > 2) devfs does not follow the LSB device naming standard.
>
> it is user-space (devfsd) issue, not kernel space (devfs)
And there is heaps of device naming going on in devfsd. As is what people
seem to be recommending.
> > Oh yeah, and there are the insolvable race conditions with the devfs
> > implementation in the kernel, but I'm not going to talk about them > right
>
> I do not argue that current devfs implementation is ugly and racy. I
> just beg you to point at what makes those races "unsolvable".
>
> > now, sorry. See the linux-kernel archives if you care about them (and
> > if you use devfs, you should care...)
>
> I do care. Searching archives for devfs mostly brings "everyone knows
> this is crap". That is why I kindly ask you to show real evidence that
> the problems it has are unsolvable.
Again I'm also unable to find descriptions of the 'unsolvable' races.
I wouldn't mind knowing what they are either. Anyone?
Ian
El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <[email protected]> escribi?:
>
> Again I'm also unable to find descriptions of the 'unsolvable' races.
>
> I wouldn't mind knowing what they are either. Anyone?
You can find tons of examples (several of them patches by Al Viro to fix them) by
searching with google with keywords like "devfs races". The "should fix" list
(http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
hch: devfs: there's a fundamental lookup vs devfsd race that's only
fixable by introducing a lookup vs devfs deadlock. I can't see how this is
fixable without getting rid of the current devfsd design. Mandrake seems
to have a workaround for this so this is at least not triggered so easily,
but that's not what I'd consider a fix..
On Thu, 8 Jan 2004, Ian Kent wrote:
> On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
[Snip]
> > I do care. Searching archives for devfs mostly brings "everyone knows
> > this is crap". That is why I kindly ask you to show real evidence that
> > the problems it has are unsolvable.
>
> Again I'm also unable to find descriptions of the 'unsolvable' races.
>
> I wouldn't mind knowing what they are either. Anyone?
Can no one think of good search terms for these sorts of things these
days? From the first and only page of results for 'devfs unsolvable
races':
http://marc.theaimsgroup.com/?l=linux-kernel&m=105851630726585&w=2
--
Alex Goddard
agoddard at purdue.edu
On Thu, 8 Jan 2004, Alex Goddard wrote:
> On Thu, 8 Jan 2004, Ian Kent wrote:
>
> > On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
>
> [Snip]
>
> > > I do care. Searching archives for devfs mostly brings "everyone knows
> > > this is crap". That is why I kindly ask you to show real evidence that
> > > the problems it has are unsolvable.
> >
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> >
> > I wouldn't mind knowing what they are either. Anyone?
>
> Can no one think of good search terms for these sorts of things these
> days? From the first and only page of results for 'devfs unsolvable
> races':
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105851630726585&w=2
Someone else already mentioned the many, many posts by Al Viro on this
subject I was about to post a URL or two for. They make for good (and
entertainingly flame-ridden) reading.
--
Alex Goddard
agoddard at purdue.edu
On Thursday 08 January 2004 20:26, Diego Calleja wrote:
> El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <[email protected]>
escribi?:
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> >
> > I wouldn't mind knowing what they are either. Anyone?
>
> You can find tons of examples (several of them patches by Al Viro to fix
> them) by searching with google with keywords like "devfs races". The
> "should fix" list
> (http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
>
is it a gospel?
> hch: devfs: there's a fundamental lookup vs devfsd race that's only
> fixable by introducing a lookup vs devfs deadlock. I can't see how this
> is fixable without getting rid of the current devfsd design. Mandrake
> seems to have a workaround for this so this is at least not triggered so
> easily, but that's not what I'd consider a fix..
oh, well ... if you selected this example ...
Mandrake workaround it mentions was my first attempt to fix this; this did not
fix the devfs but rather fixed the user-space program that provoked this on
boot (and that was buggy irrespectively of this problem).
Current 2.6 kernel includes my fix to deadlock condition. Current -mm includes
one possible fix for race condition; Andrew Morton mentioned that it is
unlikely to be accepted due to minor changes in VFS layer; I am working on
another less intrusive fix and overall devfs cleanup.
Would you please instead of citing long obsolete paper show me real example
and explain *why* it is not fixable. Better yet, would you take some time to
try to provoke any of those huge races and report back your success (stack
trace and instructions how to reproduce them are welcome :)
Thank you
-andrey
On Thursday 08 January 2004 21:14, Alex Goddard wrote:
> On Thu, 8 Jan 2004, Ian Kent wrote:
> > On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
>
> [Snip]
>
> > > I do care. Searching archives for devfs mostly brings "everyone knows
> > > this is crap". That is why I kindly ask you to show real evidence that
> > > the problems it has are unsolvable.
> >
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> >
> > I wouldn't mind knowing what they are either. Anyone?
>
> Can no one think of good search terms for these sorts of things these
> days? From the first and only page
hmm ... that does not sound like "tons of" as someone else mentioned does it?
> of results for 'devfs unsolvable
> races':
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105851630726585&w=2
oh, that same again ... you are beating dead horse. See reply to another
similar post.
thank you
-andrey
To shorten my reply from one post to two:
I wasn't aware the lookup race had been fixed. Silly me. As to the
number of results for the terms I used, I was looking for that specific
post, as I'd cited it before. 'devfs deadlock' also returns plenty of
good (and irrelevant) results at that same archive.
On Thu, 8 Jan 2004, Andrey Borzenkov wrote:
> On Thursday 08 January 2004 20:26, Diego Calleja wrote:
> > El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <[email protected]>
> escribi?:
> > > Again I'm also unable to find descriptions of the 'unsolvable' races.
> > >
> > > I wouldn't mind knowing what they are either. Anyone?
> >
> > You can find tons of examples (several of them patches by Al Viro to fix
> > them) by searching with google with keywords like "devfs races". The
> > "should fix" list
> > (http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
> >
>
> is it a gospel?
Given akpm's track record and, the fact that he's going to be maintaining
2.6, his word is enough for me. But...
[lookup vs. devfsd deadlock]
> oh, well ... if you selected this example ...
>
> Mandrake workaround it mentions was my first attempt to fix this; this
> did not fix the devfs but rather fixed the user-space program that
> provoked this on boot (and that was buggy irrespectively of this
> problem).
>
> Current 2.6 kernel includes my fix to deadlock condition. Current -mm
> includes one possible fix for race condition; Andrew Morton mentioned
> that it is unlikely to be accepted due to minor changes in VFS layer; I
> am working on another less intrusive fix and overall devfs cleanup.
>
> Would you please instead of citing long obsolete paper show me real example
> and explain *why* it is not fixable. Better yet, would you take some time to
> try to provoke any of those huge races and report back your success (stack
> trace and instructions how to reproduce them are welcome :)
>
> Thank you
One should do one's own research. If I'd done my own better, I would've
found a better example than the one I posted previously. However, since
you seem unwilling or unable to do your own homework, and I have nearly
unlimited free time until next Monday, here's some more:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103696697201341&w=2
Some parts of that post have been fixed. I haven't taken the time to read
the rest of the thread (I don't remember that thread being very long).
However, I'm all but positive the problems Viro points out in this post
still apply:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107223747630894&w=2
These posts are out there and they are _not_ hard to find at all. That
last one was from about two weeks ago. The other is much older, and I'd
have to do some digging in ugly, ugly code to find points that still
apply. However, as I started this paragraph by saying, this stuff isn't
hard to find at all.
Please consider doing your own homework. It's not like discussion of
devfs and its problems has been rare.
Thank you.
--
Alex Goddard
agoddard at purdue.edu
> One should do one's own research. If I'd done my own better, I would've
> found a better example than the one I posted previously. However, since
> you seem unwilling or unable to do your own homework, and I have nearly
> unlimited free time until next Monday,
lucky you; I wish I could say the same :(
> here's some more:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103696697201341&w=2
>
> Some parts of that post have been fixed. I haven't taken the time to read
> the rest of the thread (I don't remember that thread being very long).
>
> However, I'm all but positive the problems Viro points out in this post
> still apply:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107223747630894&w=2
>
May I ask you once more - please show me the _unsolvable_ parts.
Articles you quote discuss devfs shortcomings and design problems;
many of them are fixed; others can be fixed; none of them are
unfixable.
thank you
-andrey
Andrey Borzenkov wrote:
>>So, how does devfs stack up to the above problems and constraints:
>> Problems:
>> 1) devfs only shows the dev entries for the devices in the system.
>
>
> Is this a problem? Where exactly this problem lies?
>
Some people like to unload their (modular) devices so they don't use
memory when not in use. This saves them a few kB.
It is then useful to have the device node sitting there anyway, functioning
as a trigger. The kernel will autoload the module when the device is opened,
but that won't happen if there's no device node to open.
This approach can be made to work with devfs too - by splitting the device
into two pieces. One that manages the device node, and autoloads the rest
when needed.
>
>> 2) devfs does not handle the need for dynamic major/minor numbers
>
>
> Neither does udev. Both take whatever driver gives them.
>
>
>> 3) devfs does not provide a way to name devices in a persistent
>> fashion.
>
>
> I am not sure what exactly you mean here.
>
Probably something like
mv /dev/hda /dev/mydisk
and have it remembered upon the next reboot. devfsd can do that though.
>
>> 4) devfs does provide a deamon that userspace programs can hook > into
>> to listen to see what devices are being created or removed.
>> Constraints:
>> 1) devfs forces the devfs naming policy into the kernel. If you
>> don't like this naming scheme, tough.
>
>
> kernel imposes naming scheme for exporting devices in sysfs. It is
> possible to get rid of devfs_name in kernel and use those names
> that must exist anyway to support udev as well. devfs has
> devfsd that can call whatever naming agent you like.
>
>
>> 2) devfs does not follow the LSB device naming standard.
>
>
> it is user-space (devfsd) issue, not kernel space (devfs)
>
>
>> 3) devfs is small, and embedded devices use it. However it is
>> implemented in non-pagable memory.
>
>
> Same for sysfs. Other Unices have pageable kernel memory. If Linux
> had it any memory based filesystem could benefit from it. I did not
> look at backing store for sysfs patches but it is likely that same
> idea could be used for devfs.
>
>
>>Oh yeah, and there are the insolvable race conditions with the devfs
>>implementation in the kernel, but I'm not going to talk about them > right
>
>
> I do not argue that current devfs implementation is ugly and racy. I
> just beg you to point at what makes those races "unsolvable".
>
They are of course not unsolvable. Those understanding them seems
to believe that a complete rewrite will be easier than the rather
invasive changes necessary to fix the races. This is why the
_current implementation_ is marked obsolete. Nobody is volunteering
to fix devfs or rewrite it though.
Helge Hafting