thinking of updating the canonical online udev document
[not sure if this is the right forum for this, but i suspect others on this list might be interested so ... there you go.] as part of a device driver course i may very well be teaching in the near future (still waiting to hear), i'm thinking of adding a sizable section on how udev works (after i figure all that out, of course.) currently, the canonical udev document is this one: http://reactivated.net/writing_udev_rules.html but as good as that doc is, it's obvious that it's getting a bit dated. for example, it refers to separate udev-related utilities such as udevinfo, udevtrigger and so on when, these days, there's just "udevadm" with the appropriate subcommand, so that's something that could be tidied up. other picky things to be updated include claiming that the default udev rules file is /etc/udev/rules.d/50-udev.rules when -- at least on my ubuntu system -- it's /lib/udev/rules.d/50-udev-default.rules. again, not serious, just something that could be corrected. (mind you, i don't know if the udev file and directory structure differs drastically on other distros, something i'll look into.) and sometimes the documentation is not clear on some issues. for instance, are the only two possible entries for the udev.conf file udev_root udev_log the man page for "udev" suggests that, i just wasn't sure whether there were any other possibilities. finally, i was checking the default udev rules file on my ubuntu system and, right at the top, i read: SUBSYSTEM=="block", SYMLINK{unique}+="block/%M:%m" SUBSYSTEM!="block", SYMLINK{unique}+="char/%M:%m" AFAICT, there is nothing in the udev man page that explains the "SYMLINK{unique}" notation. it's easy enough to see how it creates that set of symlinks based on major and minor numbers, but what's with the "unique"? oh, and for this udev tutorial, i want to come up with some real, hands-on examples, so that people can see what's happening with events when they do stuff like insert USB keys and so on. anyway, this will undoubtedly take more than a few days but feel free to use this as a thread to go through the current document, check it against your system, post differences or updates, and i'll collect them all and eventually write up an updated version and post it somewhere. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
Hi, I browse through the whole net looking how to build a single module from drivers/staging. Tried this on /usr/src/linux: make M=drivers/staging/xgifb/ modules And it worked... root@zeta-pc:/usr/src/linux# make M=drivers/staging/xgifb/ modules CC [M] drivers/staging/xgifb/XGI_main_26.o CC [M] drivers/staging/xgifb/vb_init.o CC [M] drivers/staging/xgifb/vb_setmode.o CC [M] drivers/staging/xgifb/vb_util.o CC [M] drivers/staging/xgifb/vb_ext.o LD [M] drivers/staging/xgifb/xgifb.o Building modules, stage 2. MODPOST 1 modules CC drivers/staging/xgifb/xgifb.mod.o LD [M] drivers/staging/xgifb/xgifb.ko Now when I try another one it does not work: root@zeta-pc:/usr/src/linux# make M=drivers/staging/sm7xx modules Building modules, stage 2. MODPOST 0 modules root@zeta-pc:/usr/src/linux# make drivers/staging/sm7xx/ CHK include/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh I think maybe this is because I need to enable the module by on config. Am I right? Ezequiel.
Hi All I hope I'm enriching the discussion and not hijacking it So what is the difference between 1- make M=./drivers/staging/tm6000 modules 2- make ./drivers/staging/tm6000/tm6000.ko because from (1) I get linking error (ld: no input files), while I get a module that cannot be inserted (Invalid format, no symbols in module_layout) from (2) on kernel 2.6.35 Cheers, Tayssir 2011/4/26 Greg KH <greg@kroah.com>
On Tue, Apr 26, 2011 at 05:41:12AM -0700, Ezequiel García wrote:
I think maybe this is because I need to enable the module by on config. Am I right?
Yes.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
2011/4/27 Tayssir Alkowatly <idoit.ief@gmail.com>:
Hi All
I hope I'm enriching the discussion and not hijacking it
So what is the difference between 1- make M=./drivers/staging/tm6000 modules 2- make ./drivers/staging/tm6000/tm6000.ko
IMHO: (1) compiles (according to config) every modules that belong to that directory (2) directly compile that module no matter whether it is chosen or not -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Tue, Apr 26, 2011 at 08:12:44AM -0400, Robert P. J. Day wrote:
[not sure if this is the right forum for this, but i suspect others on this list might be interested so ... there you go.]
The linux-hotplug@vger.kernel.org list is where this should be discussed, please take it there.
as part of a device driver course i may very well be teaching in the near future (still waiting to hear), i'm thinking of adding a sizable section on how udev works (after i figure all that out, of course.)
currently, the canonical udev document is this one:
That doc could almost be removed entirely now, as no one should need to mess with udev rules "by hand" anymore thanks to devtmpfs and the default udev rules that are in all distros (with one notable exception.) What is your goal in redoing this? Why would a user/developer ever need to mess with udev on their own anymore? Ideally, it should all "just work" now, and I think it does given your previous emails about the confusion as to how your driver was automagically creating the correct device nodes without any help from you :) thanks, greg k-h
That doc could almost be removed entirely now, as no one should need to mess with udev rules "by hand" anymore thanks to devtmpfs and the default udev rules that are in all distros (with one notable exception.)
What is your goal in redoing this? Why would a user/developer ever need to mess with udev on their own anymore?
Well, I would! :) We're working on an embedded platform and can't use a complete distro. But we still want some good-bits from the desktop world, to be available for our system. And udev is one such thing we're trying to use (for USB plug and play kind of a feature). Apart from having a custom vendor-supplied kernel, pretty much everything else in the user-space has to be "hand-coded" by us. Or is there another 'convenient' alternative? Thanks, -mandeep
On Tue, Apr 26, 2011 at 06:35:58PM +0530, Mandeep Sandhu wrote:
That doc could almost be removed entirely now, as no one should need to mess with udev rules "by hand" anymore thanks to devtmpfs and the default udev rules that are in all distros (with one notable exception.)
What is your goal in redoing this? Why would a user/developer ever need to mess with udev on their own anymore?
Well, I would! :)
We're working on an embedded platform and can't use a complete distro. But we still want some good-bits from the desktop world, to be available for our system. And udev is one such thing we're trying to use (for USB plug and play kind of a feature).
udev is used in the "embedded" world all the time, there's no reason you can't just take the shipping tarball and use it in your product just fine. But discussion about any problems you have with that, would not be answered by the document described originally, you can just ask them on the linux-hotplug@vger.kernel.org list.
Apart from having a custom vendor-supplied kernel, pretty much everything else in the user-space has to be "hand-coded" by us.
Or is there another 'convenient' alternative?
Use the provided tools and don't roll your own. It will save you time and frustration. Look at all of the mess that people have gone through to try to re-do udev on their own already and the problems they had with it (google in android, busybox version of udev, etc.) good luck, greg k-h
udev is used in the "embedded" world all the time, there's no reason you can't just take the shipping tarball and use it in your product just fine.
We actually ended up doing just that (i.e use the latest udev from source), while building another component for our platform - NetworkManager. :)
But discussion about any problems you have with that, would not be answered by the document described originally, you can just ask them on the linux-hotplug@vger.kernel.org list.
Ok, thanks.
Use the provided tools and don't roll your own. It will save you time and frustration. Look at all of the mess that people have gone through to try to re-do udev on their own already and the problems they had with it (google in android, busybox version of udev, etc.)
Totally agree. We'd love to use all the existing open-source components out there...and we're making a conscious effort towards that, i.e reuse of existing desktop/embedded components and not write our won stuff. Thanks, -mandeep
good luck,
greg k-h
On Tue, 26 Apr 2011, Greg KH wrote:
On Tue, Apr 26, 2011 at 08:12:44AM -0400, Robert P. J. Day wrote:
[not sure if this is the right forum for this, but i suspect others on this list might be interested so ... there you go.]
The linux-hotplug@vger.kernel.org list is where this should be discussed, please take it there.
as part of a device driver course i may very well be teaching in the near future (still waiting to hear), i'm thinking of adding a sizable section on how udev works (after i figure all that out, of course.)
currently, the canonical udev document is this one:
That doc could almost be removed entirely now, as no one should need to mess with udev rules "by hand" anymore thanks to devtmpfs and the default udev rules that are in all distros (with one notable exception.)
What is your goal in redoing this? Why would a user/developer ever need to mess with udev on their own anymore?
Ideally, it should all "just work" now, and I think it does given your previous emails about the confusion as to how your driver was automagically creating the correct device nodes without any help from you :)
so you don't see much need for that level of detail for udev anymore? at the very least, i can see the need for what i asked about before -- how a misc device suddenly showed up under /dev, and with what properties. is there a doc explaining that somewhere? because i definitely went looking before i asked that question here. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Tue, Apr 26, 2011 at 09:06:02AM -0400, Robert P. J. Day wrote:
On Tue, 26 Apr 2011, Greg KH wrote:
On Tue, Apr 26, 2011 at 08:12:44AM -0400, Robert P. J. Day wrote:
[not sure if this is the right forum for this, but i suspect others on this list might be interested so ... there you go.]
The linux-hotplug@vger.kernel.org list is where this should be discussed, please take it there.
as part of a device driver course i may very well be teaching in the near future (still waiting to hear), i'm thinking of adding a sizable section on how udev works (after i figure all that out, of course.)
currently, the canonical udev document is this one:
That doc could almost be removed entirely now, as no one should need to mess with udev rules "by hand" anymore thanks to devtmpfs and the default udev rules that are in all distros (with one notable exception.)
What is your goal in redoing this? Why would a user/developer ever need to mess with udev on their own anymore?
Ideally, it should all "just work" now, and I think it does given your previous emails about the confusion as to how your driver was automagically creating the correct device nodes without any help from you :)
so you don't see much need for that level of detail for udev anymore? at the very least, i can see the need for what i asked about before -- how a misc device suddenly showed up under /dev, and with what properties.
You want a "how does this all work" type document, which is aimed for a developer, not a user, right? That's different from the above mentioned document in quite a number of ways.
is there a doc explaining that somewhere? because i definitely went looking before i asked that question here.
I wrote something like that a long time ago for LDD3 and later updated it for lwn.net I think, if you want to start with that. good luck, greg k-h
participants (6)
-
Ezequiel García -
Greg KH -
Mandeep Sandhu -
Mulyadi Santosa -
Robert P. J. Day -
Tayssir Alkowatly