All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Berger <gmane@reliableembeddedsystems.com>
To: poky@pokylinux.org
Subject: Re: Debugging udev
Date: Sat, 03 Sep 2011 13:20:50 +0300	[thread overview]
Message-ID: <j3sv23$rbe$1@dough.gmane.org> (raw)
In-Reply-To: <4E5D200B.20209@mlbassoc.com>

Hi Gary,

I'm currently on the road and can not try it myself on a yocto/poky, so
here are some wild guesses and ideas...

On 08/30/2011 08:38 PM, Gary Thomas wrote:
> I'm having trouble with udev creating all the devices I need in
> my system.  Based on the latest master, using udev 164.
> 
> My system is based on the 3.0 kernel (mainline, not yocto) with
> Video4Linux enabled with OMAP3 ISP.  This creates a bunch of
> special devices:
>   # ls /sys/class/video4linux/
>   v4l-subdev0  v4l-subdev3  v4l-subdev6  video0       video3       video6
>   v4l-subdev1  v4l-subdev4  v4l-subdev7  video1       video4
>   v4l-subdev2  v4l-subdev5  v4l-subdev8  video2       video5
> However, udev is not actually creating the device nodes.
> 
> Any ideas why?
> Any hints on how to debug this?

*) make sure udev is running - I guess it is.
*) run on a terminal something like udevmonitor --env or udevadm monitor
(don't know which one comes with poky) and load some kernel modules
where udev works. Like this you should be able to see the messages sent
by the kernel to udev. Manually load v4l so you can see if the kernel
events are sent.
*) if messages are sent, you most likely need to cook the udev config to
create the proper devices for you
*) Manually you could do make the /dev entries like this:

If you run

find /sys -name dev

you will get many hits, such as:

/sys/block/fd0/dev

cat /sys/block/fd0/dev
2:0

means if loading this module, one should also create its device as follows:
mknod /dev/fd0 b 2 0

Your goal should be to make a 'dev' entry appear under /sys for your
device and then udev (and mdev in embedded busybox systems) will mknod
it automatically.

*) DEVTMPFS
Besides I'm not a big fan of udev/mkdev for embedded systems since we
have user space dependencies. The kernel obviously knows about the v4l
class, but there are no device entries made.

I prefer to use DEVTMPFS (enable CONFIG_DEVTMPFS in your kernel config)
where the kernel makes the dev entries and you don't have user space
dependencies.

> 
> Thanks
> 

I hope this gives you some new ideas;)

Regards,

Robert


..."Experience is what causes a person to make new mistakes instead of
old ones."

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1




  reply	other threads:[~2011-09-03 10:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-30 17:38 Debugging udev Gary Thomas
2011-09-03 10:20 ` Robert Berger [this message]
2011-09-03 17:02   ` Koen Kooi
2011-09-03 20:01     ` Robert Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='j3sv23$rbe$1@dough.gmane.org' \
    --to=gmane@reliableembeddedsystems.com \
    --cc=poky@pokylinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.