J. Scott Kasten wrote: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.
Wakko Warner wrote:
Is it at all possible that if /dev/console does not exist that the kernelYes, 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.
can mknod it?
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).
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.
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)