Re: Generating diffs to 1.3.2

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

>I've finally had some time to trawl through all of the code and some of the
>patches that haven't made it (BTW I hadn't realised you were a ham :-)).
>One thing that I noticed was that apart from libc things there are quite a
>few server's with patches outstanding and some of the core utils. As I'm
>going to be repatching (I really need the shared libs and syslog code) 'til
>early in the morning do you want me to resend patch files against the 1.3.2
>sources?

:-> got my general license way back in junior high. My wife's a ham, too
(though that isn't what got us together)!

Actually, it would be best if you prioritized and only sent back in the
patches which you think REALLY should be present for the next release.
Then, between the core team, I'd dearly like to get /tcp, RCS, and a remote
filesystem working. Oh, also probably touch up vstafs.

Then I want to put all the source in a VSTa filesystem with protection set
appropriately. So /vsta/libc would be owner vsta.libc, vsta/os would be
vsta.os, vsta/srv/mach/scsi might be vsta.srv.scsi. Then you can hand out
ID's for people based on what they work on; I get "vsta", and thus inherit
access to the tree. A server guru would get vsta.srv, and would get access
to all the servers (including vsta.srv.scsi, since he dominates that label
and thus inherits its full access).

Default access to the tree is read, so anybody at all can mount it and read
the current state.

>One other thing - does mkshlib and mkshlib.c really want to live in libc
>rather than bin?

Yes; they're tools only used to build the libraries.

>BTW I finally figured out a way to port BSD code with the nasty file
>operations - it means writing a script to translate the file ops to new
>names say bsd_* and then writing bsd_* functions that store extra
>side-information but it should work OK and won't impose too much extra code
>size overhead now that we have shared libs. I'll see if I can get some time
>to write this before the end of the year :-)

Yes, that would work. I don't know if you want to support this subrosa
information across exec(), though. That would be harder, although the
mechanism currently used should be generalized anyway.

                                                        Andy
Received on Mon Oct 3 07:42:13 1994