LinuxLists.cc - [GIT PATCH] Remove devfs from 2.6.13

2005-09-09 21:46:12

Subject: [GIT PATCH] Remove devfs from 2.6.13

2005-09-10 08:26:50

by Mike Bell

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Fri, Sep 09, 2005 at 02:45:42PM -0700, Greg KH wrote:
> Also, if people _really_ are in love with the idea of an in-kernel
> devfs, I have posted a patch that does this in about 300 lines of code,
> called ndevfs.

Except that as I mentioned, it's broken by design. It creates yet
another incompatible naming scheme for devices, and what's worse the
devices it breaks are the ones like ALSA and the input subsystem, whose
locations are hard-coded into libraries. Unless sysfs is going to get
attributes from which the proper names could be derived, it won't ever
work.

2005-09-10 09:03:19

by Michael Thonke

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

Hello Greg,

just for understanding the problem right. Some questions.
Greg KH schrieb:

>Here are the same "delete devfs" patches that I submitted for 2.6.12.
>It rips out all of devfs from the kernel and ends up saving a lot of
>space. Since 2.6.13 came out, I have seen no complaints about the fact
>that devfs was not able to be enabled anymore, and in fact, a lot of
>different subsystems have already been deleting devfs support for a
>while now, with apparently no complaints (due to the lack of users.)
>
>
How could users really say/complain what brakage they have, in fact they
don't even know the relationship between all that
( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

They aren't all developers to encrypt the "magic" bug reports/debug messages
spreading over the screen.

>I mean, how can you go wrong with deleting over 8000 lines of kernel
>code :)
>
>
Right, it's a good/right work to remove dispensable code from kernel.
Even it makes it easier to maintain the code but what happen if
there is an "for now" an unresolved/unknown problem which no one notice
so far?

Devfs is in for many years, why removing it in just some weeks?

>So, please pull from:
>
>Please pull from:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
>or if master.kernel.org hasn't synced up yet:
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
>
>I've posted all of these patches before, but if people really want to look at them, they can be found at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/
>
>Also, if people _really_ are in love with the idea of an in-kernel
>devfs, I have posted a patch that does this in about 300 lines of code,
>called ndevfs. It is available in the archives if anyone wants to use
>that instead (it is quite easy to maintain that patch outside of the
>kernel tree, due to it only needing 3 hooks into the main kernel tree.)
>
>
I think this is a bad solution because on the one hand you "force" to
remove devfs due it's crappy
naming sheme and on the other hand offering to add such thing again
which brakes ALSA and other. *confused*
Even if it has only 300 lines of code.

This is not consistent with the intention to remove devfs forever.
Either say "live with it or die" or leave it as it is.

>thanks,
>
>greg k-h
>
>
Thanks for your patience Greg

Best regards

--
Michael Thonke

2005-09-10 12:34:19

by Douglas McNaught

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

Michael Thonke <[email protected]> writes:

>>Here are the same "delete devfs" patches that I submitted for 2.6.12.
>>It rips out all of devfs from the kernel and ends up saving a lot of
>>space. Since 2.6.13 came out, I have seen no complaints about the fact
>>that devfs was not able to be enabled anymore, and in fact, a lot of
>>different subsystems have already been deleting devfs support for a
>>while now, with apparently no complaints (due to the lack of users.)
>>
>>
> How could users really say/complain what brakage they have, in fact they
> don't even know the relationship between all that
> ( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

If you don't know that stuff, or aren't willing to learn and report
bugs, don't run a kernel.org kernel--stick with your distro.

> Devfs is in for many years, why removing it in just some weeks?

It's been slated for removal for quite a while, and it was completely
disabled in the last kernel release.

-Doug

2005-09-10 14:15:29

by J.A. Magallon

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On 09.09, Greg KH wrote:
> Here are the same "delete devfs" patches that I submitted for 2.6.12.
> It rips out all of devfs from the kernel and ends up saving a lot of
> space. Since 2.6.13 came out, I have seen no complaints about the fact
> that devfs was not able to be enabled anymore, and in fact, a lot of
> different subsystems have already been deleting devfs support for a
> while now, with apparently no complaints (due to the lack of users.)
>
> I mean, how can you go wrong with deleting over 8000 lines of kernel
> code :)
>
> So, please pull from:
>
> Please pull from:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
> or if master.kernel.org hasn't synced up yet:
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
>
> I've posted all of these patches before, but if people really want to look at them, they can be found at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/
>
> Also, if people _really_ are in love with the idea of an in-kernel
> devfs, I have posted a patch that does this in about 300 lines of code,
> called ndevfs. It is available in the archives if anyone wants to use
> that instead (it is quite easy to maintain that patch outside of the
> kernel tree, due to it only needing 3 hooks into the main kernel tree.)
>

I've been running kernel.org kernels on Mandrake since eons ago, and
since many time without devfs, just with static /dev or with udev.
I still have to find an application that has a devfs path hardcoded or
even as default, everything is like /dev/dvd, not /dev/ide/0/7/disk3...
Everythig works: sound, net, etc.

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam3 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

2005-09-10 21:56:19

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 11:03:28AM +0200, Michael Thonke wrote:
> Hello Greg,
>
> just for understanding the problem right. Some questions.
> Greg KH schrieb:
>
> >Here are the same "delete devfs" patches that I submitted for 2.6.12.
> >It rips out all of devfs from the kernel and ends up saving a lot of
> >space. Since 2.6.13 came out, I have seen no complaints about the fact
> >that devfs was not able to be enabled anymore, and in fact, a lot of
> >different subsystems have already been deleting devfs support for a
> >while now, with apparently no complaints (due to the lack of users.)
> >
> >
> How could users really say/complain what brakage they have, in fact they
> don't even know the relationship between all that
> ( e.g drivers -> devfs -> sysfs or other programs that rely on devfs)?

Their machines would not boot. :)

> They aren't all developers to encrypt the "magic" bug reports/debug messages
> spreading over the screen.

What do you mean?

> >I mean, how can you go wrong with deleting over 8000 lines of kernel
> >code :)
> >
> >
> Right, it's a good/right work to remove dispensable code from kernel.
> Even it makes it easier to maintain the code but what happen if
> there is an "for now" an unresolved/unknown problem which no one notice
> so far?
>
> Devfs is in for many years, why removing it in just some weeks?

It's been told and widly known that it was going to be removed last
July. In July 2004 this happened, so people have known for over a year.
How much longer do you expect me to give people?

> I think this is a bad solution because on the one hand you "force" to
> remove devfs due it's crappy naming sheme and on the other hand
> offering to add such thing again which brakes ALSA and other.
> *confused* Even if it has only 300 lines of code.
>
> This is not consistent with the intention to remove devfs forever.
> Either say "live with it or die" or leave it as it is.

"die." :)

I never said that ndevfs was to be a solution for anyone, just for
people who really complained about Linux not having an in-kernel
devfs-like solution. And if they worry about this, then they can keep
that patch outside of the main kernel tree for their distros quite
easily.

thanks,

greg k-h

2005-09-10 21:56:18

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 01:27:34AM -0700, Mike Bell wrote:
> On Fri, Sep 09, 2005 at 02:45:42PM -0700, Greg KH wrote:
> > Also, if people _really_ are in love with the idea of an in-kernel
> > devfs, I have posted a patch that does this in about 300 lines of code,
> > called ndevfs.
>
> Except that as I mentioned, it's broken by design. It creates yet
> another incompatible naming scheme for devices, and what's worse the
> devices it breaks are the ones like ALSA and the input subsystem, whose
> locations are hard-coded into libraries. Unless sysfs is going to get
> attributes from which the proper names could be derived, it won't ever
> work.

I didn't say it was a "nice" solution, fully LSB compliant and all. All
it is is a solution that can work for some people, if they just want a
small, in-kernel devfs-like solution.

And it works just fine for alsa and input devices for me, just no
subdirs :)

Anyway, I'm not offering it up for inclusion in the kernel tree at all,
but for a proof-of-concept for those who were insisting that it was
impossible to keep a devfs-like patchset out of the main kernel tree
easily.

thanks,

greg k-h

2005-09-10 23:02:27

by Mike Bell

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 02:52:54PM -0700, Greg KH wrote:
> I didn't say it was a "nice" solution, fully LSB compliant and all. All
> it is is a solution that can work for some people, if they just want a
> small, in-kernel devfs-like solution.

It's not a solution if it doesn't /work/. If you think this works for
anyone who likes devfs, you clearly still don't understand what said
people like about devfs in the first place.

> And it works just fine for alsa and input devices for me, just no
> subdirs :)

What version of alsa libraries are you using that can deal with the
device nodes in the root of /dev? I'm grepping the latest source code
right now and I don't see it. Or is this yet another one of those facts
you just made up? In what sense can alsa be said to work if zero alsa
programs work?

> Anyway, I'm not offering it up for inclusion in the kernel tree at
> all, but for a proof-of-concept for those who were insisting that it
> was impossible to keep a devfs-like patchset out of the main kernel
> tree easily.

You can use ndevfs, if you don't care about your device nodes working.
However that kind of defeats the purpose. To have a /working/ devfs-like
solution you need the names, and currently the only way to get those is
the devfs hooks.

Nobody is obligating you to provide a working ndevfs, but don't claim
it's a solution when it's not. A devfs-like solution whose device nodes
have random names which break programs is copying the form of devfs
(exporting nodes from kernel space) and ignoring the point of devfs.

2005-09-10 23:24:12

by J.A. Magallon

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On 09.09, Greg KH wrote:
> Here are the same "delete devfs" patches that I submitted for 2.6.12.

Would this be accompained with deleting all the devfs compat scripts in
udev (for 069) ? ;)

Or at least a split in a different package ?

Thanks.

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam3 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

2005-09-10 23:31:31

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 11:24:12PM +0000, J.A. Magallon wrote:
>
> On 09.09, Greg KH wrote:
> > Here are the same "delete devfs" patches that I submitted for 2.6.12.
>
> Would this be accompained with deleting all the devfs compat scripts in
> udev (for 069) ? ;)

That is only 1 file, which starts out with the following statement:
# The use of these rules is not recommended or supported.

how much more obvious do you want us udev developers to make it? :)

thanks,

greg k-h

2005-09-11 00:48:31

by David Lang

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Fri, 9 Sep 2005, Greg KH wrote:

> Date: Fri, 9 Sep 2005 14:45:42 -0700
> From: Greg KH <[email protected]>
> To: Linus Torvalds <[email protected]>, Andrew Morton <[email protected]>
> Cc: [email protected]
> Subject: [GIT PATCH] Remove devfs from 2.6.13
>
> Here are the same "delete devfs" patches that I submitted for 2.6.12.
> It rips out all of devfs from the kernel and ends up saving a lot of
> space. Since 2.6.13 came out, I have seen no complaints about the fact
> that devfs was not able to be enabled anymore, and in fact, a lot of
> different subsystems have already been deleting devfs support for a
> while now, with apparently no complaints (due to the lack of users.)

do you really think that there have been that many people who have shifted
to 2.6.13 in less then 2 weeks since release?

I know that you take personal offense to this code existing, but Andrew
pointed out when you proposed these patches before that we need to be
acareful here

David Lang

2005-09-11 03:12:15

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 05:48:05PM -0700, David Lang wrote:
> On Fri, 9 Sep 2005, Greg KH wrote:
>
> >Date: Fri, 9 Sep 2005 14:45:42 -0700
> >From: Greg KH <[email protected]>
> >To: Linus Torvalds <[email protected]>, Andrew Morton <[email protected]>
> >Cc: [email protected]
> >Subject: [GIT PATCH] Remove devfs from 2.6.13
> >
> >Here are the same "delete devfs" patches that I submitted for 2.6.12.
> >It rips out all of devfs from the kernel and ends up saving a lot of
> >space. Since 2.6.13 came out, I have seen no complaints about the fact
> >that devfs was not able to be enabled anymore, and in fact, a lot of
> >different subsystems have already been deleting devfs support for a
> >while now, with apparently no complaints (due to the lack of users.)
>
> do you really think that there have been that many people who have shifted
> to 2.6.13 in less then 2 weeks since release?

Ok, how long should I wait then?

> I know that you take personal offense to this code existing, but Andrew
> pointed out when you proposed these patches before that we need to be
> acareful here

I know, that's fine. But if I don't keep trying, how will it ever
happen? :)

thanks,

greg k-h

2005-09-11 06:09:02

by David Lang

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, 10 Sep 2005, Greg KH wrote:

> On Sat, Sep 10, 2005 at 05:48:05PM -0700, David Lang wrote:
>> On Fri, 9 Sep 2005, Greg KH wrote:
>>
>>> Here are the same "delete devfs" patches that I submitted for 2.6.12.
>>> It rips out all of devfs from the kernel and ends up saving a lot of
>>> space. Since 2.6.13 came out, I have seen no complaints about the fact
>>> that devfs was not able to be enabled anymore, and in fact, a lot of
>>> different subsystems have already been deleting devfs support for a
>>> while now, with apparently no complaints (due to the lack of users.)
>>
>> do you really think that there have been that many people who have shifted
>> to 2.6.13 in less then 2 weeks since release?
>
> Ok, how long should I wait then?

if 2.6.13 removed the devfs config option, then I would say the code
itself should stay until 2.6.15 or 2.6.16 (if the release schedule does
drop down to ~2 months then it would need to be at lease .16). especially
with so many people afraid of the 2.6 series you need to wait at least one
full release cycle, probably two (and possibly more if they end up being
short ones) then rip out the rest of the code for the following release.

remember that the distros don't package every kernel, they skip several
between releases and it's not going to be until they go to try them that
all the kinks will get worked out.

add to this the fact that many people have gotten confused about kernel
releases and think that since 13 is odd 2.6.13 is a testing kernel and
2.6.14 will be a stable one and so won't look at .13

note that all this assumes that the issues that people have about sysfs
not yet being able to replace that capabilities that they are useing in
devfs have been addressed.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-11 06:10:41

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 04:03:12PM -0700, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 02:52:54PM -0700, Greg KH wrote:
> > I didn't say it was a "nice" solution, fully LSB compliant and all. All
> > it is is a solution that can work for some people, if they just want a
> > small, in-kernel devfs-like solution.
>
> It's not a solution if it doesn't /work/. If you think this works for
> anyone who likes devfs, you clearly still don't understand what said
> people like about devfs in the first place.

Said people who like devfs are lazy and don't like running userspace
programs. They pretty much also are pretty restricted to embedded
systems. That's all I have been able to determine so far. Care to help
flush this profile out some?

> > And it works just fine for alsa and input devices for me, just no
> > subdirs :)
>
> What version of alsa libraries are you using that can deal with the
> device nodes in the root of /dev? I'm grepping the latest source code
> right now and I don't see it. Or is this yet another one of those facts
> you just made up? In what sense can alsa be said to work if zero alsa
> programs work?

My applogies, I used the OSS compatible module for ALSA when I tested
this out. Hey, might as well use 1990's style interfaces, for 1990's
style kernel features... :)

> > Anyway, I'm not offering it up for inclusion in the kernel tree at
> > all, but for a proof-of-concept for those who were insisting that it
> > was impossible to keep a devfs-like patchset out of the main kernel
> > tree easily.
>
> You can use ndevfs, if you don't care about your device nodes working.
> However that kind of defeats the purpose. To have a /working/ devfs-like
> solution you need the names, and currently the only way to get those is
> the devfs hooks.

Hm, ok, ALSA will not work. Can you point to anything else? Who cares
about sound on embedded systems anyway...

> Nobody is obligating you to provide a working ndevfs, but don't claim
> it's a solution when it's not. A devfs-like solution whose device nodes
> have random names which break programs is copying the form of devfs
> (exporting nodes from kernel space) and ignoring the point of devfs.

I'm claiming that the people who insisted that keeping the devfs
patchset outside of the mainline kernel was impossible. I show how to
do this with 3 calls to "add a node" and three calls to "remove a node",
in a total of only 2 different kernel files. Such a patch is _easily_
maintainable for pretty much forever outside the kernel tree. Distros
maintain patches _way_ more complex and rough than that all the time.

That is my main point about ndevfs.

thanks,

greg k-h

2005-09-11 07:06:16

by Arjan van de Ven

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, 2005-09-10 at 23:08 -0700, David Lang wrote:
>
> remember that the distros don't package every kernel

nor do distros use devfs :)

2005-09-11 07:14:28

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:

> remember that the distros don't package every kernel, they skip several
> between releases and it's not going to be until they go to try them that
> all the kinks will get worked out.

I'll bite - what distros are shipping a kernel 2.6.10 or later and still
using devfs?

Attachments:

(No filename) (226.00 B)

2005-09-11 07:20:28

by David Lang

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, 11 Sep 2005 [email protected] wrote:

> On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:
>
>> remember that the distros don't package every kernel, they skip several
>> between releases and it's not going to be until they go to try them that
>> all the kinks will get worked out.
>
> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?
>
I'll admit I don't keep track of the distros and what kernels and features
they are useing. I think I've heard people mention gentoo, but I
haven't verified this.

however with the thousands of linux distros out there I'd lay odds that
_someone_ is doing it ;-)

That said, my comments about the schedule should apply to any significant
feature, not just devfs, it just happens to be the current patch being
discussed. If Greg hadn't asked me how long I thought he needed to wait I
would have dropped out after my initial post, but he asked so I answered.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

2005-09-11 11:02:25

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> >using devfs?
> >
> I'll admit I don't keep track of the distros and what kernels and features
> they are useing. I think I've heard people mention gentoo, but I
> haven't verified this.

Nope, not Gentoo --- Greg KH fixed gentoo a while ago. :-)

> however with the thousands of linux distros out there I'd lay odds that
> _someone_ is doing it ;-)

Yes, but if none of the major distributions are doing it, then past a
certain point we should just pull the trigger and be done with it.
C'mon, devfs's impending removal has been announced for a year. It's
not like anyone can complain that they didn't get enough warning.....

- Ted

2005-09-11 11:35:46

by Bastian Blank

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, Sep 11, 2005 at 03:13:53AM -0400, [email protected] wrote:
> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?

Debian unstable

Bastian

--
Many Myths are based on truth
-- Spock, "The Way to Eden", stardate 5832.3

Attachments:

(No filename) (272.00 B)
signature.asc (197.00 B)
Digital signature Download all attachments

2005-09-11 11:42:34

by CaT

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, Sep 11, 2005 at 01:35:35PM +0200, Bastian Blank wrote:
> On Sun, Sep 11, 2005 at 03:13:53AM -0400, [email protected] wrote:
> > I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> > using devfs?
>
> Debian unstable

sid can hardly be called a shippable distro. that'd be like pulling
some code at a random time out of a cvs repository that's still in
development (ie sid ;) and calling it a release version.

--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby

2005-09-11 11:44:45

by George Spelvin

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

> I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> using devfs?

Debian. The current Debian installer is unfortunately rather tightly
coupled to devfs; the reasons for choosing it are rooted in boot floppy
size, but the development ("unstable") install image uses 2.6.12 + devfs.

I just had to do a little dance to install it on a machine where
2.6.12 didn't recognize the SATA controller but 2.6.13 counldn't
run the installer.

Note that Debian doesn't need devfs in normal operation; it's just
a bootstrapping tool.

2005-09-11 15:43:23

by Kyle Moffett

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sep 11, 2005, at 07:44:35, [email protected] wrote:
>> I'll bite - what distros are shipping a kernel 2.6.10 or later and
>> still
>> using devfs?
>
> Debian. The current Debian installer is unfortunately rather tightly
> coupled to devfs; the reasons for choosing it are rooted in boot
> floppy
> size, but the development ("unstable") install image uses 2.6.12 +
> devfs.
>
> I just had to do a little dance to install it on a machine where
> 2.6.12 didn't recognize the SATA controller but 2.6.13 counldn't
> run the installer.
>
> Note that Debian doesn't need devfs in normal operation; it's just
> a bootstrapping tool.

That sounds like _exactly_ the case where the Debian folks could
maintain
the out-of-tree ndevfs patch for a while until they got their installer
floppies and such migrated to udev.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E
W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5
X R?
tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------

2005-09-11 17:20:28

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 11:08:36PM -0700, David Lang wrote:
> remember that the distros don't package every kernel, they skip several
> between releases and it's not going to be until they go to try them that
> all the kinks will get worked out.

I don't know of any major distro that ships devfs with a 2.6 kernel, do
you?

> add to this the fact that many people have gotten confused about kernel
> releases and think that since 13 is odd 2.6.13 is a testing kernel and
> 2.6.14 will be a stable one and so won't look at .13

Well, they should not think this, a number of us have been trying our
best to get the word out as to how the current kernel development cycle
works.

> note that all this assumes that the issues that people have about sysfs
> not yet being able to replace that capabilities that they are useing in
> devfs have been addressed.

Hm, that happened a long time ago...

Unless anyone else knows of anything missing?

thanks,

greg k-h

2005-09-11 17:20:29

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> On Sun, 11 Sep 2005 [email protected] wrote:
>
> >On Sat, 10 Sep 2005 23:08:36 PDT, David Lang said:
> >
> >>remember that the distros don't package every kernel, they skip several
> >>between releases and it's not going to be until they go to try them that
> >>all the kinks will get worked out.
> >
> >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> >using devfs?
> >
> I'll admit I don't keep track of the distros and what kernels and features
> they are useing. I think I've heard people mention gentoo, but I
> haven't verified this.

Haha, no, Gentoo does not use devfs for it's 2.6 kernels at all. I
should know, I'm a Gentoo developer too :)

thanks,

greg k-h

2005-09-12 08:01:36

by Martin Schlemmer

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, 2005-09-11 at 07:02 -0400, Theodore Ts'o wrote:
> On Sun, Sep 11, 2005 at 12:20:06AM -0700, David Lang wrote:
> > >I'll bite - what distros are shipping a kernel 2.6.10 or later and still
> > >using devfs?
> > >
> > I'll admit I don't keep track of the distros and what kernels and features
> > they are useing. I think I've heard people mention gentoo, but I
> > haven't verified this.
>

Why do people always remember us as using devfs, instead of being one of
the first distro's supporting it (if not the first) ? :( I already
added support for udev to the initscripts back in Sep 2003, and added
the udev-0.2 package to the tree in Oct 2003.

> Nope, not Gentoo --- Greg KH fixed gentoo a while ago. :-)
>

Not entirely true, but he did start to maintain the udev package around
udev-022.

--
Martin Schlemmer

Attachments:

signature.asc (189.00 B)
This is a digitally signed message part

2005-09-12 13:40:41

by Steven Rostedt

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, 2005-09-10 at 22:09 -0700, Greg KH wrote:

>
> Hm, ok, ALSA will not work. Can you point to anything else? Who cares
> about sound on embedded systems anyway...

Hmm, a quiet PS2? I don't think people would go for that ;-)

Not that the PS2 runs Linux, but yes there are embedded systems that do
require sound.

-- Steve

2005-09-14 20:00:01

by Mike Bell

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> Said people who like devfs are lazy and don't like running userspace
> programs.

I hardly consider myself lazy or a hater of user space programs. I've
been an early adopter running unstable series kernels and testing out
new features since long before devfs went into the kernel. In the past
I've been quick to switch over to new ways of doing things as they came
into the kernel, even when it required a fair bit of time and effort to
migrate.

What I don't like is when someone arbitrarily declares that their
half-finished project obsoletes a working one, and yet even a full year
later with a massive development community using the latest kernel
features (sometimes added specifically for that project) it isn't a full
replacement for a project that has been - in your own words -
unmaintained for years and years.

> They pretty much also are pretty restricted to embedded systems.
> That's all I have been able to determine so far. Care to help flush
> this profile out some?

Probably because they're the people building linux systems from scratch
and caring about the size and speed of the result?

> My applogies, I used the OSS compatible module for ALSA when I tested
> this out.

And while some input subsystem users force you to specify a device node,
this method is incompatible with hotplugging so the more advanced ones
rely on finding the input device nodes where they're supposed to be, as
they should.

> Hm, ok, ALSA will not work. Can you point to anything else?

See above. And of course ndevfs doesn't create the device nodes that udev
doesn't support (yes, even in 2.6.12 devfs still supported more devices
than udev on my test system). Those are just the things that bit me on
the one system I tried ndevfs on before deciding there was no way to
make it work without adding sysfs attributes.

> Who cares about sound on embedded systems anyway...

People who make audio players, SIP phones, PMPs, multimedia displays,
information kiosks, set top boxes, security monitoring devices and PA
systems, to give just a few examples of embedded systems that need sound
and are currently made with linux. And even though embedded linux is
still in its infancy, I would guess that it's responsible for more linux
systems in people's hands than most distributions.

> I'm claiming that the people who insisted that keeping the devfs
> patchset outside of the mainline kernel was impossible. I show how to
> do this with 3 calls to "add a node" and three calls to "remove a node",
> in a total of only 2 different kernel files. Such a patch is _easily_
> maintainable for pretty much forever outside the kernel tree. Distros
> maintain patches _way_ more complex and rough than that all the time.

How is that anything of the sort? ndevfs doesn't work, and isn't even
remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
the kernel tree. But since ndevfs has absolutely nothing to do with
devfs, that doesn't change the fact that devfs can't be maintained out
of the kernel tree. Your reasoning makes no sense.

Anyway, if things continue the way they are with intentional
devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
you'll get your wish soon enough when backhanded devfs removal makes the
in-tree version useless.

2005-09-14 20:00:36

by Mike Bell

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sun, Sep 11, 2005 at 11:43:02AM -0400, Kyle Moffett wrote:
> That sounds like _exactly_ the case where the Debian folks could
> maintain the out-of-tree ndevfs patch for a while until they got their
> installer floppies and such migrated to udev.

Then you know nothing about the subject at hand. Moving from devfs to
ndevfs is dramatically /harder/ than moving from devfs to udev. ndevfs
is not devfs compatible in any way, shape or form.

2005-09-14 20:14:12

by Kyle Moffett

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Sep 14, 2005, at 16:01:24, Mike Bell wrote:
> On Sun, Sep 11, 2005 at 11:43:02AM -0400, Kyle Moffett wrote:
>> That sounds like _exactly_ the case where the Debian folks could
>> maintain the out-of-tree ndevfs patch for a while until they got
>> their installer floppies and such migrated to udev.
>
> Then you know nothing about the subject at hand. Moving from devfs
> to ndevfs is dramatically /harder/ than moving from devfs to udev.
> ndevfs is not devfs compatible in any way, shape or form.

The debian installer has devfs paths coded into it, ok, sure. The
reason it used devfs was so it didn't need extra userspace stuff to
create device nodes. It seems like the installer could be reasonably
easily converted to use different path names without changing any
_real_ code at all, and from there all you need to do is add the
ndevfs patch to the kernel. It's probably about as difficult to add
the udev userspace stuff at the right point in the boot process (you
still need to change all the pathnames), as it is to add the ndevfs
patch to the kernel. On the other hand, the latter _might_ result in
a smaller floppy image, which is what the Debian developers really
wanted/needed. I suppose it would be nice if the busybox people
added basic udev-type functionality, but it's not really all that
necessary.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer

2005-09-14 20:29:05

by Kyle Moffett

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

[ CC list trimmed to spare Linus and Andrew the mailbox clutter ]

On Sep 14, 2005, at 16:00:49, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
>> Said people who like devfs are lazy and don't like running
>> userspace programs.
>
> What I don't like is when someone arbitrarily declares that their
> half-finished project obsoletes a working one, and yet even a full
> year later with a massive development community using the latest
> kernel features (sometimes added specifically for that project) it
> isn't a full
> replacement for a project that has been - in your own words -
> unmaintained for years and years.

What exactly does devfs do that udev doesn't, exactly? I haven't
been able to find anything on my wide variety of hardware, although I
will admit that there are some drivers that do not yet fully/
correctly use the new driver model.

>> They pretty much also are pretty restricted to embedded systems.
>> That's all I have been able to determine so far. Care to help
>> flush this profile out some?
>
> Probably because they're the people building linux systems from
> scratch and caring about the size and speed of the result?

udev isn't that big or that slow, especially not the new netlink-
socket version, so unless you can provide a concrete example, I'm not
entirely sure what you're talking about.

>> My applogies, I used the OSS compatible module for ALSA when I
>> tested this out.
>
> And while some input subsystem users force you to specify a device
> node, this method is incompatible with hotplugging so the more
> advanced ones rely on finding the input device nodes where they're
> supposed to be, as they should.

What makes you think specifying nodes is incompatible with
hotplugging? I have my USB mouse and keyboard show up as /dev/
gyration_mouse and /dev/macally_keyboard, and I point my little input
event program at those. Admittedly, X kinda gets confused when I
unplug and those go away, but X doesn't support hotplugging anyways.

>> Hm, ok, ALSA will not work. Can you point to anything else?
>
> See above. And of course ndevfs doesn't create the device nodes
> that udev doesn't support (yes, even in 2.6.12 devfs still
> supported more devices than udev on my test system).

So there are broken non-new-driver-model drivers. If you depend on
them (especially if you depend on them for your commercial product),
please feel free to fix them, because otherwise they won't be, and
they'll get more out of date with every kernel release until somebody
deletes them because they're unmaintained.

> ...before deciding there was no way to make it work without adding
> sysfs attributes.

See above. Feel free to fix the driver if you need it.

>> I'm claiming that the people who insisted that keeping the devfs
>> patchset outside of the mainline kernel was impossible. I show
>> how to do this with 3 calls to "add a node" and three calls to
>> "remove a node", in a total of only 2 different kernel files.
>> Such a patch is _easily_ maintainable for pretty much forever
>> outside the kernel tree. Distros maintain patches _way_ more
>> complex and rough than that all the time.
>
> ndevfs doesn't work,

Yes it does. It works correctly for me.

> and isn't even remotely compatible with devfs.

So? You need to change your /dev paths _now_. You've known that
those paths were kinda going away for a _long_ time, so it's not like
you haven't had time to fix your code that used them. And if you
need a kernel-generated /dev, then ndevfs will work (albeit with sane
paths, as opposed to the old devfs /dev/ide/host0/bus0/... crap).

> Yes, ndevfs is easy to maintain out of the kernel tree. But since
> ndevfs has absolutely nothing to do with devfs, that doesn't change
> the fact that devfs can't be maintained out of the kernel tree.

devfs can't be maintained _within_ the kernel tree, let alone _out_
of it. Besides, it contained unfixable races, etc.

> Anyway, if things continue the way they are with intentional devfs-
> breakage having moved from out-of-tree drivers to in-tree drivers,
> you'll get your wish soon enough when backhanded devfs removal
> makes the in-tree version useless.

This sentence doesn't parse, perhaps you'd like to clarify? In any
case, devfs is going away because it's sufficiently racy and broken
and has been marked as DEPRECATED for a year. udev _has_ been
completely working for a while, even if not for the full year.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare

2005-09-14 23:14:44

by Greg KH

[permalink] [raw]

Subject: Re: [GIT PATCH] Remove devfs from 2.6.13

On Wed, Sep 14, 2005 at 01:00:49PM -0700, Mike Bell wrote:
> On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> > Said people who like devfs are lazy and don't like running userspace
> > programs.
>
> I hardly consider myself lazy or a hater of user space programs. I've
> been an early adopter running unstable series kernels and testing out
> new features since long before devfs went into the kernel. In the past
> I've been quick to switch over to new ways of doing things as they came
> into the kernel, even when it required a fair bit of time and effort to
> migrate.
>
> What I don't like is when someone arbitrarily declares that their
> half-finished project obsoletes a working one, and yet even a full year
> later with a massive development community using the latest kernel
> features (sometimes added specifically for that project) it isn't a full
> replacement for a project that has been - in your own words -
> unmaintained for years and years.

What part of devfs does udev not support? From what I remember, the
first version of udev, a binary about 5k in size, pretty much
implemented all of what devfs did.

Remember that the main goal of udev is persistant names, which devfs can
not do at all.

> > They pretty much also are pretty restricted to embedded systems.
> > That's all I have been able to determine so far. Care to help flush
> > this profile out some?
>
> Probably because they're the people building linux systems from scratch
> and caring about the size and speed of the result?

Size is smaller with udev, you have a userspace program, no unswapable
kernel memory. Speed is probably even faster, have you tried udev using
the netlink interface?

> > My applogies, I used the OSS compatible module for ALSA when I tested
> > this out.
>
> And while some input subsystem users force you to specify a device node,
> this method is incompatible with hotplugging so the more advanced ones
> rely on finding the input device nodes where they're supposed to be, as
> they should.

I don't understand the problem here. input devices work just fine with
ndevfs, you just have to point your program to the proper node, as
ndevfs does not support subdirectories.

> > Hm, ok, ALSA will not work. Can you point to anything else?
>
> See above.

You didn't point out any specific devices that ndevfs doesn't support.

> And of course ndevfs doesn't create the device nodes that udev
> doesn't support (yes, even in 2.6.12 devfs still supported more devices
> than udev on my test system).

What devices are lacking udev support? I don't know of any in-kernel
devices, with the exception of isdn (for which the maintainer of that
subsystem is working on it, along with a major rewrite).

> Those are just the things that bit me on the one system I tried ndevfs
> on before deciding there was no way to make it work without adding
> sysfs attributes.

Again, which devices do not have sysfs support? I'll fix that up.

> > Who cares about sound on embedded systems anyway...
>
> People who make audio players, SIP phones, PMPs, multimedia displays,
> information kiosks, set top boxes, security monitoring devices and PA
> systems, to give just a few examples of embedded systems that need sound
> and are currently made with linux. And even though embedded linux is
> still in its infancy, I would guess that it's responsible for more linux
> systems in people's hands than most distributions.

That was a joke...

> > I'm claiming that the people who insisted that keeping the devfs
> > patchset outside of the mainline kernel was impossible. I show how to
> > do this with 3 calls to "add a node" and three calls to "remove a node",
> > in a total of only 2 different kernel files. Such a patch is _easily_
> > maintainable for pretty much forever outside the kernel tree. Distros
> > maintain patches _way_ more complex and rough than that all the time.
>
> How is that anything of the sort? ndevfs doesn't work, and isn't even
> remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
> the kernel tree. But since ndevfs has absolutely nothing to do with
> devfs, that doesn't change the fact that devfs can't be maintained out
> of the kernel tree. Your reasoning makes no sense.

My reasoning was that people who insisted that maintaining something
like devfs outside of the kernel was impossible. I showed that this is
not true with the 3-hour hack of ndevfs. If you, or anyone else wants
to turn it into a "true" devfs replacement, feel free. That was my
point.

> Anyway, if things continue the way they are with intentional
> devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
> you'll get your wish soon enough when backhanded devfs removal makes the
> in-tree version useless.

Yeah, I have noticed this, my devfs-removal patch is getting smaller and
smaller every release.

Remember, devfs was marked OBSOLETE way over a year ago (and not by me).
And way back in July of 2004 I stated that it would be removed in July
of 2005. That gave everyone over a year. How much longer do you expect
me to wait?

thanks,

greg k-h

2005-09-15 02:10:47

by Ioan Ionita

[permalink] [raw]

Subject: Re: Remove devfs from 2.6.13

Kill it now and ignore these die-hard fanatics. They just can't
imagine a world in which there's no devfs to be found anywhere in the
kernel. When nostalgia takes over them, someone can just show them the
way to the kernel archives. There have been much greater changes in
the kernel than the proposed removal of a system that has become
nothing more than a fat pile of dead, stinky decomposing code, laying
around waiting for someone to burry it in the past and get rid of the
stench.

On 9/14/05, Greg KH <[email protected]> wrote:
> On Wed, Sep 14, 2005 at 01:00:49PM -0700, Mike Bell wrote:
> > On Sat, Sep 10, 2005 at 10:09:06PM -0700, Greg KH wrote:
> > > Said people who like devfs are lazy and don't like running userspace
> > > programs.
> >
> > I hardly consider myself lazy or a hater of user space programs. I've
> > been an early adopter running unstable series kernels and testing out
> > new features since long before devfs went into the kernel. In the past
> > I've been quick to switch over to new ways of doing things as they came
> > into the kernel, even when it required a fair bit of time and effort to
> > migrate.
> >
> > What I don't like is when someone arbitrarily declares that their
> > half-finished project obsoletes a working one, and yet even a full year
> > later with a massive development community using the latest kernel
> > features (sometimes added specifically for that project) it isn't a full
> > replacement for a project that has been - in your own words -
> > unmaintained for years and years.
>
> What part of devfs does udev not support? From what I remember, the
> first version of udev, a binary about 5k in size, pretty much
> implemented all of what devfs did.
>
> Remember that the main goal of udev is persistant names, which devfs can
> not do at all.
>
> > > They pretty much also are pretty restricted to embedded systems.
> > > That's all I have been able to determine so far. Care to help flush
> > > this profile out some?
> >
> > Probably because they're the people building linux systems from scratch
> > and caring about the size and speed of the result?
>
> Size is smaller with udev, you have a userspace program, no unswapable
> kernel memory. Speed is probably even faster, have you tried udev using
> the netlink interface?
>
> > > My applogies, I used the OSS compatible module for ALSA when I tested
> > > this out.
> >
> > And while some input subsystem users force you to specify a device node,
> > this method is incompatible with hotplugging so the more advanced ones
> > rely on finding the input device nodes where they're supposed to be, as
> > they should.
>
> I don't understand the problem here. input devices work just fine with
> ndevfs, you just have to point your program to the proper node, as
> ndevfs does not support subdirectories.
>
> > > Hm, ok, ALSA will not work. Can you point to anything else?
> >
> > See above.
>
> You didn't point out any specific devices that ndevfs doesn't support.
>
> > And of course ndevfs doesn't create the device nodes that udev
> > doesn't support (yes, even in 2.6.12 devfs still supported more devices
> > than udev on my test system).
>
> What devices are lacking udev support? I don't know of any in-kernel
> devices, with the exception of isdn (for which the maintainer of that
> subsystem is working on it, along with a major rewrite).
>
> > Those are just the things that bit me on the one system I tried ndevfs
> > on before deciding there was no way to make it work without adding
> > sysfs attributes.
>
> Again, which devices do not have sysfs support? I'll fix that up.
>
> > > Who cares about sound on embedded systems anyway...
> >
> > People who make audio players, SIP phones, PMPs, multimedia displays,
> > information kiosks, set top boxes, security monitoring devices and PA
> > systems, to give just a few examples of embedded systems that need sound
> > and are currently made with linux. And even though embedded linux is
> > still in its infancy, I would guess that it's responsible for more linux
> > systems in people's hands than most distributions.
>
> That was a joke...
>
> > > I'm claiming that the people who insisted that keeping the devfs
> > > patchset outside of the mainline kernel was impossible. I show how to
> > > do this with 3 calls to "add a node" and three calls to "remove a
> node",
> > > in a total of only 2 different kernel files. Such a patch is _easily_
> > > maintainable for pretty much forever outside the kernel tree. Distros
> > > maintain patches _way_ more complex and rough than that all the time.
> >
> > How is that anything of the sort? ndevfs doesn't work, and isn't even
> > remotely compatible with devfs. Yes, ndevfs is easy to maintain out of
> > the kernel tree. But since ndevfs has absolutely nothing to do with
> > devfs, that doesn't change the fact that devfs can't be maintained out
> > of the kernel tree. Your reasoning makes no sense.
>
> My reasoning was that people who insisted that maintaining something
> like devfs outside of the kernel was impossible. I showed that this is
> not true with the 3-hour hack of ndevfs. If you, or anyone else wants
> to turn it into a "true" devfs replacement, feel free. That was my
> point.
>
> > Anyway, if things continue the way they are with intentional
> > devfs-breakage having moved from out-of-tree drivers to in-tree drivers,
> > you'll get your wish soon enough when backhanded devfs removal makes the
> > in-tree version useless.
>
> Yeah, I have noticed this, my devfs-removal patch is getting smaller and
> smaller every release.
>
> Remember, devfs was marked OBSOLETE way over a year ago (and not by me).
> And way back in July of 2004 I stated that it would be removed in July
> of 2005. That gave everyone over a year. How much longer do you expect
> me to wait?
>
> thanks,
>
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>