Device node - How does kernel know about it
Siva Prasad
sprasad at bivio.net
Fri Dec 28 15:55:04 EST 2007
Jon,
Yes!... I have CONFIG_EARLY_PRINTK=y, and I could see early prints
during booting the kernel. Afterwards, printk's also work as expected.
Only printf's from user space has problem.
- Siva
-----Original Message-----
From: Jon Smirl [mailto:jonsmirl at gmail.com]
Sent: Thursday, December 27, 2007 8:16 PM
To: Siva Prasad
Cc: Nicholas Mc Guire; linuxppc-dev at ozlabs.org;
linuxppc-embedded at ozlabs.org
Subject: Re: Device node - How does kernel know about it
On 12/27/07, Siva Prasad <sprasad at bivio.net> wrote:
> Thank you Jon and Nicholas.
>
> I already have "console=ttyS0" in the kernel command line. That is not
> helping me.
Do you have
CONFIG_EARLY_PRINTK=y
in .config?
>
> I looked at the major/minor numbers with a good working system and it
> looks correct for the nodes created in ramdisk.
>
> What is the kernel routine that is first called when there is, for
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
>
> Thanks
> Siva
>
>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:der.herr at hofr.at]
> Sent: Friday, December 28, 2007 12:39 AM
> To: Siva Prasad
> Cc: linuxppc-dev at ozlabs.org; linuxppc-embedded at ozlabs.org
> Subject: Re: Device node - How does kernel know about it
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > * Ramdisk is also executing fine, just that prints are not coming
out
> of
> > serial. I can see the execution of various user programs with a
printk
> > in sys_execve() routine. Ramdisk has all the required files like
> > /dev/console, /dev/ttyS0, etc.
> > * Looking further into tty driver, I noticed that call to
tty_write()
> or
> > do_tty_write() is not happening at all. So, somewhere the interface
> > between kernel and user program is lost.
> > * Just to check it out, I tried to write a small kernel module and a
> > test program.
> > - Attached memtest.c module (not really testing memory there. :-))
> > - Attached testmemtest.c user program, that just open's it and
reads
> > the information
> > - Created a device node using "mknod /dev/memtest c 168 0"
> > - When I do "insmod memtest.ko" inside the ramdisk bootup scripts,
I
> > could see all the printk's on the console
> > - When I execute "testmemtest" next in the same script, it does not
> > display the printk inside of memtest.c module. This only indicates
> that
> > read call did not really go to the kernel side.
> > - Just to check my program's validity, I checked on a similar
machine
> > and all the code works fine.
> > - "uname -r" also matches with what I built. So, chances of exiting
> > from open call because of mismatch is remote. Since userland cannot
> > print, I have no idea what exactly is happening there.
> >
> The kernel will simply look at the major:minor numbers - so maybe you
> simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
> see nothing but other than that most things will go on working.
>
> hofrat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
> hrfpn2RMn5l23ZqCOXV5rd8=
> =GfsF
> -----END PGP SIGNATURE-----
>
--
Jon Smirl
jonsmirl at gmail.com
More information about the Linuxppc-dev
mailing list