From: Zack Weinberg <zack@codesourcery.com>
To: linux-kernel@vger.kernel.org
Subject: Re: udev: what's up with old /dev ?
Date: Mon, 11 Oct 2004 00:19:13 -0700 [thread overview]
Message-ID: <878yadwwlq.fsf@codesourcery.com> (raw)
Hacksaw writes:
>Zack Weinberg writes:
>>The very first thing init does is open /dev/console, and if it doesn't
>>exist the entire boot hangs.
>
>This raises a question: Would it be a useful thing to make a modified init
>that could run udev before it does anything else?
It wouldn't help. The opening of /dev/console actually happens inside
the kernel, near the bottom of init/main.c:
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk("Warning: unable to open an initial console.\n");
(void) sys_dup(0);
(void) sys_dup(0);
That's not a fatal error, but the userspace startup process does get
stuck not very long afterward. (I'm not sure precisely where. It
hadn't mounted filesystems read-write yet.)
Control reaches the above code after an initramfs is unpacked, so
including /dev/console in an initramfs will work. I do not think it
will work to invoke udevstart from an initramfs or initrd *without*
also including a static /dev/console -- I'm pretty darn sure that
control reaches /init in an initramfs after the above code executes.
I'm not sure whether control reaches /linuxrc in an initrd before or
after the above code.
Being inside the kernel at this point, it seems to me there ought to
be some way to open device <5,1> without going through the filesystem,
but I could not find one.
[Tangentially, I thought kernel-side syscalls had been stamped out,
but there's still a __KERNEL_SYSCALLS__ #define at the top of the file
and a bare execve() in run_init_process()... which does in fact get
compiled to int $0x80 on my boring old x86...]
zw
next reply other threads:[~2004-10-11 7:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-11 7:19 Zack Weinberg [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-10-10 22:41 udev: what's up with old /dev ? Michael Thonke
2004-10-10 22:08 J.A. Magallon
2004-10-10 22:51 ` Zack Weinberg
2004-10-10 23:15 ` Hacksaw
2004-10-10 23:25 ` J.A. Magallon
2004-10-11 0:06 ` Hacksaw
2004-10-11 19:13 ` Denis Vlasenko
2004-10-11 9:14 ` Felipe Alfaro Solana
2004-10-11 10:29 ` Arkadiusz Miskiewicz
2004-10-11 12:02 ` Felipe Alfaro Solana
2004-10-11 11:11 ` Hacksaw
2004-10-11 12:04 ` Felipe Alfaro Solana
2004-10-11 20:06 ` Hacksaw
2004-10-11 20:51 ` Bartlomiej Zolnierkiewicz
2004-10-11 21:28 ` Hacksaw
2004-10-12 0:19 ` Greg KH
2004-10-12 8:11 ` Harald Dunkel
2004-10-12 16:58 ` Greg KH
[not found] ` <416C26B4.6040408@t-online.de>
[not found] ` <20041012185733.GA31222@kroah.com>
[not found] ` <416C3BB6.4040200@t-online.de>
[not found] ` <20041012203022.GB32139@kroah.com>
2004-10-12 21:35 ` Harald Dunkel
2004-10-13 13:08 ` Mathieu Segaud
2004-10-13 14:13 ` Harald Dunkel
2004-10-13 14:33 ` Mathieu Segaud
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=878yadwwlq.fsf@codesourcery.com \
--to=zack@codesourcery.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox