Re: [RFC] automount based devfs replacement

From: A. Haumer (andreas@xss.co.at)
Date: Tue Apr 18 2000 - 02:03:14 EST


Hi!

Erik Andersen wrote:
>
> On Mon Apr 17, 2000 at 08:26:34PM +0200, A. Haumer wrote:
> >
> [-------snip--------]
> > On our diskless clients we boot from the network and mount our root-fs
> > from a NFS server read-only. The system is still a fully functional
> [-------snip--------]
> >
> > Before we had devfs we couldnīt really solve the problem of having
> > writable devicefiles on a readonly filesystem.
>
> You do not need devfs for this at all. Just do something like the following.
> Takes 100k of ramdisk (could use much less if you trim your device list to only
> the devices you really need):
>
Hm...

> #!/bin/sh
> echo -n "Building device ramdisk: "
> SIZE=100
> INODES=1200
> dd if=/dev/zero of=/dev/ram1 bs=1k count=$SIZE > /dev/null 2>&1
> mkfs.minix -n30 -i $INODES /dev/ram1 $SIZE > /dev/null 2>&1
> mount /dev/ram1 /mnt -t minix -o rw > /dev/null 2>&1
> cp -a /dev/* /mnt > /dev/null 2>&1
> umount /dev/ram1 > /dev/null 2>&1
> mount /dev/ram1 /dev -t minix -o rw > /dev/null 2>&1
> echo "done."
>
> Now you have a readonly root filesystem with writable devicefiles.
> Apply similar methods to /tmp, /var, or wherever you need to write
> stuff,
>
Well, that's what I consider a real "hack". Not what *I* want to
have in my production systems... :-)

What if you want to change something in your device structure,
e.g. when a new device driver is loaded? You have to rebuild
your device ramdisk! We want a generic solution for our product,
and devfs gives us just that!

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:12 EST