[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: On links and things (LONG)

On Wed, 2 Feb 1994 Mark_Weaver@brown.edu wrote:

> Many people used links (hard and soft) in NetBSD for devices as well.
> If a link was used for a device which getty was servicing, there were
> some problems.  The "tty" program would use the major/minor device
> numbers to try to find the name of the original device file, and it
> was undefined which link it would come up with.  In practice, it was
> probably dependent on the order of the files in the directory
> (unsorted), but isn't easily controllable.
> In particular, sometimes the TERM variable would be set incorrectly
> because it was looking that device name up in the /etc/ttys file,
> which only contains one of the link names.
> The solution was to:
>  1. Only use symlinks in /dev
>  2. Make 'tty' always give the name of a non-symlink
>  3. Use the non-symlink names in /etc/ttys
> ..and there were no more problems...
> I am against the use of hard links in /dev simply because there is no
> way to tell the original from the link.

I did realise that there were problems with lock files, but didn't know 
the details, and I was saying enough already. The reason that there are 
problems is because programs try to lock a file, rather than a device. 
Because the device has multiple names, there is a problem managing 
contention. If every program ignored that file system name space and 
locked on major & minor device numbers, there wouldn't be that problem. 
Anyway, that's all water under the bridge, and not for discussion here.

You've convinced me about symlinks in /dev.

> Perl is great, and I use it all the time, but it may not fit on the
> boot floppy.  I really like the fact that the base installation fits
> on only three disks.

I haven't done the work yet, but perl could be a lot smaller if you left 
out some stuff - sockets come to mind. Size isn't the big issue anyway. 
A rather feeble interactive shell, called for example, /bin/sh can be 
done in a few lines of perl, and you won't need sed, and maybe a few 
other things. Whether you *need* bash or not on the boot floppy depends 
on whether there are other shell scripts which can't be redone in perl.

> > [...]  I think that we should be accounting file space
> > used/free/available for every package selected/deselected, which would
> > be difficult in shell, but not too hard in perl.  But since you and Ian
> > have made your minds up, there's no point in discussing that, eh?
> Search for "Arithmetic Expansion" in the bash(1) man page.  Besides,
> it is easy using a few simple filters to get the info out of 'df'.

It's not so much the arithmetic that's missing as the difficulty of the 
parsing. In order to do package size accounting, you need a database of 
directory and size pairs, which need to be matched against the partition 
mount points. For example, elm.tgz from debian 0.81:

11      var
10      var/adm
9       var/adm/packages
632     usr
521     usr/bin
22      usr/doc
33      usr/lib
32      usr/lib/elm
55      usr/man
54      usr/man/man1

[ This generated by:
gunzip -c comm/elm.tgz | tar xf - ; find var usr -type d -print | xargs du -s ]

If the mount points are / and /usr, then we have / 11 and /usr 632 used.
If the mount points are / and /usr/lib, then we have / (11 + 632 - 33) 
and /usr 33.

That should be enough to see what I mean. The matching, logic and 
arithmetic would be much easier to do in perl, especially, I think if a 
dbm file was used for the data, although I haven't used dbm files myself. 
Before anyone throws out the idea, think how much benefit could be 
obtained from knowing how much space you have *before* doing any package 
installation, when you can still easily add or subtract a few packages, 
change the mount points or re-arrange the partition sizes. The package 
usage information is easy to generate, and easy (I'm guessing) to convert 
to a dbm file if that was useful.

I'm not suggesting that we do this overnight, but I think it is useful 
and worth striving for, so that we can have the *best* installation 

Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
  but no simpler"   Einstein, A  | Fax: (02) 413 6868 Pacing Systems    \/  

Reply to: