thinking of updating the canonical online udev document

thinking of updating the canonical online udev document

[Robert P. J. Day]

  [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
========================================================================

Compiling single module

[Ezequiel García]

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 at 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 at zeta-pc:/usr/src/linux# make M=drivers/staging/sm7xx modules
? Building modules, stage 2.
? MODPOST 0 modules
root at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110426/f2ff1d7c/attachment-0001.html 

Compiling single module

[Greg KH]

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.

Compiling single module

[Tayssir Alkowatly]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110427/c4695f93/attachment.html 

Compiling single module

[Mulyadi Santosa]

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

thinking of updating the canonical online udev document

[Greg KH]

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 at 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:
> 
>   http://reactivated.net/writing_udev_rules.html

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

thinking of updating the canonical online udev document

[Mandeep Sandhu]

> 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

thinking of updating the canonical online udev document

[Greg KH]

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 at 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

thinking of updating the canonical online udev document

[Mandeep Sandhu]

> 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 at 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
>

thinking of updating the canonical online udev document

[Robert P. J. Day]

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 at 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:
> >
> >   http://reactivated.net/writing_udev_rules.html
>
> 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
========================================================================

thinking of updating the canonical online udev document

[Greg KH]

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 at 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:
> > >
> > >   http://reactivated.net/writing_udev_rules.html
> >
> > 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