Wakko Warner wrote:
J. Scott Kasten wrote:
Wakko Warner wrote:
Is it at all possible that if /dev/console does not exist that the kernel
can mknod it?
Yes, you could modify the kernel source to create the directory and
device nodes for you if you must. I have written a few embedded drivers
that created their access nodes that way.
That's interesting. All I wanted to do was create /dev and /dev/console if
they don't exist. The project I was working on was a 2 stage where stage 1
loads stage 2 (stage 1 is small enough for floppy use). Since space is a
concern, I was wondering if the entries in a cpio archive would be more or
less bytes compared to the code in the kernel to do it. At the moment I
have a vanilla kernel that I'm using (2.6.12-rc5).
Have you considered making a root cramfs? I could almost guarantee that
it would be smaller, not only that, but you get a gzip like compression
for free. Now that I have a little better picture of what you are
trying to do, I would suggest using a read-only cramfs for your root
file system. You can selectively mount writeable file systems over it.
In fact, at the end of your "boot strapping process", you could
pivot_root/chroot into a live file system on disk then drop the cramfs.
I use this procedure on the flash of my Zaurus. It boots a cramfs image
from the on-board flash which then loads the SD card driver, checks some
things out, and finally mounts and chroots into a 512MB flash card with
a nearly stock debian image on ext2.
Actually, even debian uses this type of procedure to fsck the disks and
look for new devices before turning control over to the disk based system.
You can also modify the arch/xxx/startup.c file and change the inital
console to /dev/null or just NULL if you need too. However, I will warn
you of some bad experiences. I found that tar, and the bash shell
sometimes misbehave with no terminal. They would inexplicably hang
unless I forced I/O paths 0, 1, 2 to /dev/null. Tar and the shell would
hang, even though they were not prompting, nor expecting input. Yet I
could set the initial console to a serial port and it would run fine,
even if the command generated no output! Very strange and hard to debug
in a restricted environment like that. Somewhere in that code, it must
have been testing the default I/O paths to see if they were tty like
devices or something and then freaking out with unexpected results.
The system will be used by console users only (mostly me), thus I can't use
/dev/null. The / is populated via a gzipped cpio archive passed via initrd.
I don't care if it's right, all that matters is that it works and is small.
My best advice in a situation like this is to actually write your own
pseudo console device driver. It's not that hard and you might actually
find a way to make it usefull for debugging. Basicly make it a console
that feeds about a 2K static ring buffer in kernel memory. That gets
you a few screen fulls of data for debugging. If you have a PC style
real-time clock, there is a 2K static ram in most of those. Or "ping"
it out through the network with magic ICMP packets. Either way, you
have created a usefull debugging tool that will be invaluable for
resolving bootstrapping problems, and you just won't have to deal with
the strangeness I mentioned above.
I don't believe I can do this. I've never written a kernel driver before.
What I built was a short lived system. As I stated, it has to be small
(stage 1 only). I can now easily reproduce the building of the kernel and
stage 1 and fit it on a floppy (that was when I upgraded from rc4 to rc5).
I had originaly had ext2 compiled in, since 1) the old initrd ramdisk image
was ext2 2) it was the only filesystem I was using that had unix file
permissions (and was writable) 3) it was actually the smallest compared to
the other ones I used. Now that I pass cpio archive to it, I no longer need
ext2 compiled in (it's on stage 2 which is either cdrom or usb disk)
I don't think you need to do all that I suggested earlier. I cam in on
the middle of this discussion and it sounded like a small embedded
environment you were trying to enhance. The cramfs image thing I
described above is probably a much better fit for your needs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
