* [9fans] Acme mailreader @ 2004-12-15 15:34 jim 2004-12-15 15:40 ` gdiaz ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: jim @ 2004-12-15 15:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi list, I've been trying and trying to get mailreading to work in acme(1) on my OS X system. It works fine on a plan9 system, e.g. mordor.tip9ug.jp, but I can't work out how to do the same thing with acme/wily on OS X. Mail is stored in mbox format, so it ought to be possible; maybe some paths need amending? OS X seems to be fairly p9 friendly; it has open(1), which is very similar to plumb(1), and lots of remote services (ftp, mail etc) are mounted as filesystems, so (despite being a "girls unix" ;-) it should be a pretty nice host OS for plan9port. Cheers, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:34 [9fans] Acme mailreader jim @ 2004-12-15 15:40 ` gdiaz 2004-12-15 15:47 ` jim 2004-12-15 16:07 ` rog 2004-12-15 16:09 ` Russ Cox 2 siblings, 1 reply; 69+ messages in thread From: gdiaz @ 2004-12-15 15:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, jim Cc: Fans of the OS Plan 9 from Bell Labs I think you need upas/fs to get that working, i don't know it that is on plan9ports yet. gabi Mensaje citado por jim <jim.whitson@gmail.com>: > Hi list, > > I've been trying and trying to get mailreading to work > in acme(1) on my OS X system. It works fine on a plan9 > system, e.g. mordor.tip9ug.jp, but I can't work out how to > do the same thing with acme/wily on OS X. Mail is stored > in mbox format, so it ought to be possible; maybe some > paths need amending? > > OS X seems to be fairly p9 friendly; it has open(1), > which is very similar to plumb(1), and lots of remote > services (ftp, mail etc) are mounted as filesystems, so > (despite being a "girls unix" ;-) it should be a pretty > nice host OS for plan9port. > > Cheers, > > jim > > > > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:40 ` gdiaz @ 2004-12-15 15:47 ` jim 2004-12-15 15:50 ` Joseph Stewart 2004-12-15 15:58 ` Charles Forsyth 0 siblings, 2 replies; 69+ messages in thread From: jim @ 2004-12-15 15:47 UTC (permalink / raw) To: gdiaz; +Cc: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 15:40, gdiaz@online.ie wrote: > I think you need upas/fs to get that working, i don't know it that is > on > plan9ports yet. Ah, I see. I'd hoped that acme could be persuaded simply to read from ~/mail/inbox.mbox, and parse the messages it finds there. Nevermind; I'll keep looking for a vmware-esque software to run plan9 in os x ;-) Thanks for your time, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:47 ` jim @ 2004-12-15 15:50 ` Joseph Stewart 2004-12-15 15:57 ` jim 2004-12-15 16:10 ` Russ Cox 2004-12-15 15:58 ` Charles Forsyth 1 sibling, 2 replies; 69+ messages in thread From: Joseph Stewart @ 2004-12-15 15:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Some folks at the qemu list (http://fabrice.bellard.free.fr/qemu/) have gotten plan9 to work under that emulator which works under OSX... I however have not... problems with the IDE driver recognizing the emulated hardware. I don't have the bandwidth to take a close look at it. -j On Wed, 15 Dec 2004 15:47:07 +0000, jim <jim.whitson@gmail.com> wrote: > > On 15 Dec 2004, at 15:40, gdiaz@online.ie wrote: > > > I think you need upas/fs to get that working, i don't know it that is > > on > > plan9ports yet. > > Ah, I see. I'd hoped that acme could be persuaded simply > to read from ~/mail/inbox.mbox, and parse the messages > it finds there. Nevermind; I'll keep looking for a vmware-esque > software to run plan9 in os x ;-) > > Thanks for your time, > > jim > > -- Person who say it cannot be done should not interrupt person doing it. -- Chinese Proverb ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:50 ` Joseph Stewart @ 2004-12-15 15:57 ` jim 2004-12-15 16:10 ` Russ Cox 1 sibling, 0 replies; 69+ messages in thread From: jim @ 2004-12-15 15:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 15:50, Joseph Stewart wrote: > Some folks at the qemu list (http://fabrice.bellard.free.fr/qemu/) > have gotten plan9 to work under that emulator which works under OSX... > Cheers for the pointer; I'm downloading it now :-D. > I however have not... problems with the IDE driver recognizing the > emulated hardware. I don't have the bandwidth to take a close look at > it. > I see. Well, my fingers are crossed, and I'll keep you posted on progress... Thanks again for the tip. jim > -j > > > On Wed, 15 Dec 2004 15:47:07 +0000, jim <jim.whitson@gmail.com> wrote: >> >> On 15 Dec 2004, at 15:40, gdiaz@online.ie wrote: >> >>> I think you need upas/fs to get that working, i don't know it that is >>> on >>> plan9ports yet. >> >> Ah, I see. I'd hoped that acme could be persuaded simply >> to read from ~/mail/inbox.mbox, and parse the messages >> it finds there. Nevermind; I'll keep looking for a vmware-esque >> software to run plan9 in os x ;-) >> >> Thanks for your time, >> >> jim >> >> > > > -- > Person who say it cannot be done should not interrupt person doing it. > -- Chinese Proverb > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:50 ` Joseph Stewart 2004-12-15 15:57 ` jim @ 2004-12-15 16:10 ` Russ Cox 1 sibling, 0 replies; 69+ messages in thread From: Russ Cox @ 2004-12-15 16:10 UTC (permalink / raw) To: Joseph Stewart, Fans of the OS Plan 9 from Bell Labs > Some folks at the qemu list (http://fabrice.bellard.free.fr/qemu/) > have gotten plan9 to work under that emulator which works under OSX... > > I however have not... problems with the IDE driver recognizing the > emulated hardware. I don't have the bandwidth to take a close look at > it. you can get the system up and running off the floppy without needing the ide driver, so maybe that's what they did. i certainly got the results you describe -- the video works fine (after i added the card to vgadb) but the ide is unrecognized. russ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:47 ` jim 2004-12-15 15:50 ` Joseph Stewart @ 2004-12-15 15:58 ` Charles Forsyth 2004-12-15 16:04 ` jim 2004-12-15 16:05 ` rog 1 sibling, 2 replies; 69+ messages in thread From: Charles Forsyth @ 2004-12-15 15:58 UTC (permalink / raw) To: 9fans >>Ah, I see. I'd hoped that acme could be persuaded simply >>to read from ~/mail/inbox.mbox, and parse the messages upas/fs centralises the parsing (and access to mail storage), so that neither acme mail nor upas/nedmail need to do quite as much parsing as most mail readers (for instance, upas/fs deals with mime). they don't touch the mailbox directly. furthermore, by having upas/fs represent messages including subcomponents as directories and subdirectories in the name space, two different mail readers can be active on the same mail box at once (with consistency enforced by upas/fs), even across machine boundaries. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:58 ` Charles Forsyth @ 2004-12-15 16:04 ` jim 2004-12-15 16:24 ` C H Forsyth 2004-12-15 16:05 ` rog 1 sibling, 1 reply; 69+ messages in thread From: jim @ 2004-12-15 16:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 15:58, Charles Forsyth wrote: > upas/fs centralises the parsing (and access to mail storage), > so that neither acme mail nor upas/nedmail need to do quite > as much parsing as most mail readers Very nice ;-). Are upas/fs as yet unported for some technical reason, or just for want of time? The techniques you speak of seem extremely interesting (not to mention useful!). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:04 ` jim @ 2004-12-15 16:24 ` C H Forsyth 2004-12-15 16:31 ` jim 0 siblings, 1 reply; 69+ messages in thread From: C H Forsyth @ 2004-12-15 16:24 UTC (permalink / raw) To: 9fans >>Very nice ;-). Are upas/fs as yet unported for some technical reason, it serves the mbox name space using the 9p protocol. most other systems can't directly act as clients (well), without non-trivial system-specific implementations of 9p client code; there is most of one for linux, but not (i think) macosx. i suppose applications that wanted to access it could just use the 9p client libraries, but that restricts it a bit. i sometimes grep and cat things in my /mail/fs ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:24 ` C H Forsyth @ 2004-12-15 16:31 ` jim 2004-12-15 17:07 ` Russ Cox 2004-12-15 18:48 ` Skip Tavakkolian 0 siblings, 2 replies; 69+ messages in thread From: jim @ 2004-12-15 16:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 16:24, C H Forsyth wrote: >>> Very nice ;-). Are upas/fs as yet unported for some technical reason, > > it serves the mbox name space using the 9p protocol. > most other systems can't directly act as clients (well), without > non-trivial system-specific implementations of 9p client code; > there is most of one for linux, but not (i think) macosx. > i suppose applications that wanted to access it could just > use the 9p client libraries, but that restricts it a bit. > Yeah, that could be a problem... My head is swimming with namespaces ;-) Let me see if i understand this properly. upas/fs parses lots of the message format, then makes available a filesystem which contains the messages in a nicer format (minus mime &c.), which is the served to clients (e.g. acme(1)) using 9p. Right? So, acme talks to my local fs (e.g. to edit a file) using unix syscall &c., but it wants to talk to mail using 9p? Presumably one can make acme look at a local fs for the mailboxes, rather than 9p? In which case, the problem is to get upas/fs to parse the messages, then mount them somewhere for acme to see... Or, perhaps I'm fundamentally misunderstanding plan 9... Cheers, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:31 ` jim @ 2004-12-15 17:07 ` Russ Cox 2004-12-15 17:30 ` jim 2004-12-15 18:36 ` Axel Belinfante 2004-12-15 18:48 ` Skip Tavakkolian 1 sibling, 2 replies; 69+ messages in thread From: Russ Cox @ 2004-12-15 17:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Let me see if i understand this properly. upas/fs parses lots of the > message > format, then makes available a filesystem which contains the messages > in a > nicer format (minus mime &c.), which is the served to clients (e.g. > acme(1)) > using 9p. Right? So, acme talks to my local fs (e.g. to edit a file) > using unix > syscall &c., but it wants to talk to mail using 9p? Presumably one can > make > acme look at a local fs for the mailboxes, rather than 9p? In which > case, the > problem is to get upas/fs to parse the messages, then mount them > somewhere > for acme to see... Or, perhaps I'm fundamentally misunderstanding plan > 9... to get a feel for what upas/fs is providing, you should poke around in /mail/fs/mbox on a real plan9 machine and look at the broken out messages -- just cd around and cat things. the plan 9 ports code posts 9p services as unix domain sockets in a magic directory in /tmp. code in the know can open the sockets and speak 9p to the servers. that's how win talks to acme, for example, and how everyone talks to the plumber. you could start with /usr/local/plan9/src/cmd/9p.c and dig down from there to see what's going on. russ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 17:07 ` Russ Cox @ 2004-12-15 17:30 ` jim 2004-12-15 18:33 ` Russ Cox 2004-12-15 18:36 ` Axel Belinfante 1 sibling, 1 reply; 69+ messages in thread From: jim @ 2004-12-15 17:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 17:07, Russ Cox wrote: > > to get a feel for what upas/fs is providing, > you should poke around in /mail/fs/mbox on a real plan9 > machine and look at the broken out messages -- just cd > around and cat things. > *jim tabs over to drawterm. *jim pokes around. Oh wow. That's really nice. I want it. > the plan 9 ports code posts 9p services as unix domain > sockets in a magic directory in /tmp. code in the know can > open the sockets and speak 9p to the servers. that's how > win talks to acme, for example, and how everyone talks > to the plumber. you could start with /usr/local/plan9/src/cmd/9p.c > and dig down from there to see what's going on. > Ah I see. So, this magic 9p socket(s) lets acme talk to upas/fs in order to get the (nicely decoded) emails? Very good. So, upas/fs maintains some kind of internal representation of the /mnt/fs/mbox? Or is it generated on-the-fly by grabbing messages? I promise I'll go away and read the source now... Thanks for your help, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 17:30 ` jim @ 2004-12-15 18:33 ` Russ Cox 2004-12-15 18:49 ` jim 0 siblings, 1 reply; 69+ messages in thread From: Russ Cox @ 2004-12-15 18:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Ah I see. So, this magic 9p socket(s) lets acme talk to upas/fs in > order to get the (nicely decoded) emails? Very good. So, upas/fs actually acme talks to Mail which talks to upas/fs, but yeah. > maintains some kind of internal representation of the /mnt/fs/mbox? this. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 18:33 ` Russ Cox @ 2004-12-15 18:49 ` jim 0 siblings, 0 replies; 69+ messages in thread From: jim @ 2004-12-15 18:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Russ Cox On 15 Dec 2004, at 18:33, Russ Cox wrote: >> Ah I see. So, this magic 9p socket(s) lets acme talk to upas/fs in >> order to get the (nicely decoded) emails? Very good. So, upas/fs > > actually acme talks to Mail which talks to upas/fs, but yeah. >> maintains some kind of internal representation of the /mnt/fs/mbox? > > this. > > Cool. It's much clearer now. There seems to be a very complete porting guide in cmd/upas/README, so my life is much easier now :-). Cheers, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 17:07 ` Russ Cox 2004-12-15 17:30 ` jim @ 2004-12-15 18:36 ` Axel Belinfante 2004-12-15 18:47 ` jim 2004-12-15 18:51 ` rog 1 sibling, 2 replies; 69+ messages in thread From: Axel Belinfante @ 2004-12-15 18:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > the plan 9 ports code posts 9p services as unix domain > sockets in a magic directory in /tmp. code in the know can > open the sockets and speak 9p to the servers. that's how > win talks to acme, for example, and how everyone talks > to the plumber. you could start with /usr/local/plan9/src/cmd/9p.c > and dig down from there to see what's going on. might that also be a way to provice access to files on a remote plan 9 file server? (e.g. to edit them via acme, or whatever) Axel. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 18:36 ` Axel Belinfante @ 2004-12-15 18:47 ` jim 2004-12-15 18:51 ` rog 1 sibling, 0 replies; 69+ messages in thread From: jim @ 2004-12-15 18:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 18:36, Axel Belinfante wrote: >> the plan 9 ports code posts 9p services as unix domain >> sockets in a magic directory in /tmp. code in the know can >> open the sockets and speak 9p to the servers. that's how >> win talks to acme, for example, and how everyone talks >> to the plumber. you could start with /usr/local/plan9/src/cmd/9p.c >> and dig down from there to see what's going on. > > might that also be a way to provice access to > files on a remote plan 9 file server? > (e.g. to edit them via acme, or whatever) > Yes, I'd assume that an acme running on a non-plan9 system could (if it could talk 9p to it) see the file on a remote plan 9 server. But, nothing else on your system (apart from plan 9 aware tools) would be able to see the mount point... > Axel. > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 18:36 ` Axel Belinfante 2004-12-15 18:47 ` jim @ 2004-12-15 18:51 ` rog 1 sibling, 0 replies; 69+ messages in thread From: rog @ 2004-12-15 18:51 UTC (permalink / raw) To: 9fans > might that also be a way to provice access to > files on a remote plan 9 file server? > (e.g. to edit them via acme, or whatever) problem is that local unix commands won't see the files, so usefulness is limited. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:31 ` jim 2004-12-15 17:07 ` Russ Cox @ 2004-12-15 18:48 ` Skip Tavakkolian 1 sibling, 0 replies; 69+ messages in thread From: Skip Tavakkolian @ 2004-12-15 18:48 UTC (permalink / raw) To: 9fans cpu% grep 'My head is swimming' /mail/fs/mbox/*/body /mail/fs/mbox/1227/body:Yeah, that could be a problem... My head is swimming with namespaces ;-) cpu% cat /mail/fs/mbox/1227/from jim.whitson@gmail.comcpu% cpu% >>>> Very nice ;-). Are upas/fs as yet unported for some technical reason, >> it serves the mbox name space using the 9p protocol. > Yeah, that could be a problem... My head is swimming with namespaces ;-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:58 ` Charles Forsyth 2004-12-15 16:04 ` jim @ 2004-12-15 16:05 ` rog 1 sibling, 0 replies; 69+ messages in thread From: rog @ 2004-12-15 16:05 UTC (permalink / raw) To: 9fans > upas/fs centralises the parsing (and access to mail storage), > so that neither acme mail nor upas/nedmail need to do quite > as much parsing as most mail readers (for instance, upas/fs > deals with mime). it's also important so that programs can see mime parts as regular files, so they can be viewed, plumbed, grepped, etc. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:34 [9fans] Acme mailreader jim 2004-12-15 15:40 ` gdiaz @ 2004-12-15 16:07 ` rog 2004-12-15 16:09 ` jim 2004-12-15 16:09 ` Russ Cox 2 siblings, 1 reply; 69+ messages in thread From: rog @ 2004-12-15 16:07 UTC (permalink / raw) To: 9fans > OS X seems to be fairly p9 friendly [...] > lots of remote services (ftp, mail etc) are mounted as filesystems does this mean they're using user-level filesystems, or that they've built ftp, mail, etc into the kernel? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:07 ` rog @ 2004-12-15 16:09 ` jim 2004-12-16 0:24 ` geoff 0 siblings, 1 reply; 69+ messages in thread From: jim @ 2004-12-15 16:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 15 Dec 2004, at 16:07, rog@vitanuova.com wrote: >> OS X seems to be fairly p9 friendly [...] >> lots of remote services (ftp, mail etc) are mounted as filesystems > > does this mean they're using user-level filesystems, > or that they've built ftp, mail, etc into the kernel? > I'm afraid I haven't got into the details of how it all works... Each user has a ~/Library, which contains various filesystems, such as ~/Library/Mail/POP-jim.whitson@gmail.com/, which contain the mboxes for email accounts. Whenever one accesses an ftp server, it ends up mounted (using /sbin/mount_ftp) there too. I assume there's some generality to this, but not enough - no-one's added sftp etc. support, which I assume someone would have done if it was properly extensible... I suppose that's evidence that it's all done in kernel-land. ugly :-(. Although, on the other hand, OS X is a micro-kernel, so it's userland in that sense... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:09 ` jim @ 2004-12-16 0:24 ` geoff 2004-12-16 4:12 ` Ronald G. Minnich ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: geoff @ 2004-12-16 0:24 UTC (permalink / raw) To: 9fans OS X is in no sense a micro-kernel. The OS X kernel is huge: ; size /mach_kernel __TEXT __DATA __OBJC others dec hex 3022848 458752 0 643984 4125584 3ef390 and consists of a heavily-hacked Mach (3, I believe) kernel and a FreeBSD kernel (with bits from other BSDs), combined into a single kernel and running in a single address space. The BSD kernel does not run in user mode. Remember that Mach was, as far as I know, the largest ``micro-kernel'' ever produced, larger than most or all of its contemporary ``macro-kernels'', so that some of us called it a ``Machro-kernel''. I haven't looked very hard (one could check out the mount_* sources from the Darwin CVS servers), but mount(2) doesn't seem to have much that's new, except for union mounts, which surprised me. I suspect that most of the mount_* commands either invoke kernel machinery (through the ``type'' argument to mount) or pretend to be NFS servers. I've never yet seen a (l)unix system other than late Research Unix that made user-mode file servers relatively easy and painless to write (though I'd love to be shown a counter-example!). Of course, since many (l)unix systems only allow the super-user to mount anything, their maintainers may not see much utility in user-mode file servers. It's sort of a cascade of vision-failures. Also, /sys/src/cmd/upas/README is a little dated: --rw-rw-r-- M 5174 sys sys 1041 Dec 11 1999 README I'm not sure if it pre-dates upas/fs, but it describes how to port the parts of upas that don't rely on Plan 9 facilities (transport more than reading). I ported Plan 9's upas back to Unix while at the labs (and also translated it into limbo), but some parts (e.g., upas/fs) didn't have an obvious implementation, other than painfully pretending to be an NFS server, at least at the time. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 0:24 ` geoff @ 2004-12-16 4:12 ` Ronald G. Minnich 2004-12-16 4:51 ` geoff 2004-12-16 5:13 ` Skip Tavakkolian 2004-12-16 8:17 ` Martin C.Atkins ` (2 subsequent siblings) 3 siblings, 2 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-16 4:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 15 Dec 2004 geoff@collyer.net wrote: > Remember that Mach was, as far as I know, the largest ``micro-kernel'' > ever produced, larger than most or all of its contemporary > ``macro-kernels'', so that some of us called it a ``Machro-kernel''. I remember a running argument on this when Mach 3.0 was released. - "It's huge" - "No, it's bigger than huge" - "No, it's even bigger than that" The flaming of the code base size continued. Then, my memory tells me, Rashid weighed in with the following comment (from memory) - "Micro kernel doesn't mean it is small, it means it does not do much" What else do you need to say? > I haven't looked very hard (one could check out the mount_* sources > from the Darwin CVS servers), but mount(2) doesn't seem to have much > that's new, except for union mounts, which surprised me. BSD union mounts are very different animals from Plan 9 union mounts, to say the least ... ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 4:12 ` Ronald G. Minnich @ 2004-12-16 4:51 ` geoff 2004-12-16 9:25 ` jim 2004-12-16 5:13 ` Skip Tavakkolian 1 sibling, 1 reply; 69+ messages in thread From: geoff @ 2004-12-16 4:51 UTC (permalink / raw) To: 9fans I wonder why people were so fascinated in the 1980s with huge programs that do very little. The X server has to be the biggest program I've ever seen that doesn't do anything for you. -K Thompson Mach 3.0 certainly did very little for you. I remember reading the code, looking for someplace that actually did something other than packing function arguments into structs and calling something else. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 4:51 ` geoff @ 2004-12-16 9:25 ` jim 0 siblings, 0 replies; 69+ messages in thread From: jim @ 2004-12-16 9:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 16 Dec 2004, at 04:51, geoff@collyer.net wrote: > I wonder why people were so fascinated in the 1980s with huge programs > that do very little. As far as I can see, a lot of people still are... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 4:12 ` Ronald G. Minnich 2004-12-16 4:51 ` geoff @ 2004-12-16 5:13 ` Skip Tavakkolian 2004-12-16 5:17 ` geoff ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Skip Tavakkolian @ 2004-12-16 5:13 UTC (permalink / raw) To: 9fans > Then, my memory tells me, Rashid weighed in with the following comment > (from memory) > - "Micro kernel doesn't mean it is small, it means it does not do much" > > What else do you need to say? Whatever happened to him? Where is he now? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:13 ` Skip Tavakkolian @ 2004-12-16 5:17 ` geoff 2004-12-16 5:20 ` boyd, rounin ` (2 more replies) 2004-12-16 5:23 ` Andy Newman 2004-12-16 15:52 ` Ronald G. Minnich 2 siblings, 3 replies; 69+ messages in thread From: geoff @ 2004-12-16 5:17 UTC (permalink / raw) To: 9fans Microsoft, last I heard. I believe he contributed some of Mach into NT. They've got Dave (D. N.) Cutler too. It's like a retirement home. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:17 ` geoff @ 2004-12-16 5:20 ` boyd, rounin 2004-12-16 5:34 ` boyd, rounin 2004-12-16 5:29 ` Skip Tavakkolian 2004-12-16 15:54 ` Ronald G. Minnich 2 siblings, 1 reply; 69+ messages in thread From: boyd, rounin @ 2004-12-16 5:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > They've got Dave (D. N.) Cutler too. It's like a retirement home. oh yeah. Digital killed Prism and he went ballistic!! hence the 'VMS' in 2000/NT. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:20 ` boyd, rounin @ 2004-12-16 5:34 ` boyd, rounin 0 siblings, 0 replies; 69+ messages in thread From: boyd, rounin @ 2004-12-16 5:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs http://www.free-definition.com/Dave-Cutler.html -- Digital badge # 248622 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:17 ` geoff 2004-12-16 5:20 ` boyd, rounin @ 2004-12-16 5:29 ` Skip Tavakkolian 2004-12-16 15:54 ` Ronald G. Minnich 2 siblings, 0 replies; 69+ messages in thread From: Skip Tavakkolian @ 2004-12-16 5:29 UTC (permalink / raw) To: 9fans > Microsoft, last I heard. I believe he contributed some of Mach into > NT. > > They've got Dave (D. N.) Cutler too. It's like a retirement home. ... for the aged and the insane ideas. BTW, the question was rhetorical :) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:17 ` geoff 2004-12-16 5:20 ` boyd, rounin 2004-12-16 5:29 ` Skip Tavakkolian @ 2004-12-16 15:54 ` Ronald G. Minnich 2004-12-16 17:52 ` Skip Tavakkolian 2004-12-16 18:13 ` Dave Eckhardt 2 siblings, 2 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-16 15:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 15 Dec 2004 geoff@collyer.net wrote: > Microsoft, last I heard. I believe he contributed some of Mach into > NT. I don't think that's it. I've been told many times that NT was the post-VMS OS that was developed at DEC by Cutler et. al. and taken en masse to MS, rumor has it that a lot of source went too. I knew a fellow who had done VMS source hackery at DEC for many years, and he said his knowledge of VMS innards made beating on NT very easy ... "it's 100% bug compatible". ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 15:54 ` Ronald G. Minnich @ 2004-12-16 17:52 ` Skip Tavakkolian 2004-12-16 18:13 ` Dave Eckhardt 1 sibling, 0 replies; 69+ messages in thread From: Skip Tavakkolian @ 2004-12-16 17:52 UTC (permalink / raw) To: 9fans >> Microsoft, last I heard. I believe he contributed some of Mach into >> NT. > > I don't think that's it. I've been told many times that NT was the > post-VMS OS that was developed at DEC by Cutler et. al. and taken en masse > to MS, rumor has it that a lot of source went too. I knew a fellow who had > done VMS source hackery at DEC for many years, and he said his knowledge > of VMS innards made beating on NT very easy ... "it's 100% bug > compatible". My vague recollection from "Show-stopper" seems to support this. He hired (I think 5) members of the team from DEC, who became the core of the kernel team. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 15:54 ` Ronald G. Minnich 2004-12-16 17:52 ` Skip Tavakkolian @ 2004-12-16 18:13 ` Dave Eckhardt 1 sibling, 0 replies; 69+ messages in thread From: Dave Eckhardt @ 2004-12-16 18:13 UTC (permalink / raw) To: 9fans > I've been told many times that NT was the post-VMS OS that was > developed at DEC by Cutler et. al. and taken en masse to MS, > rumor has it that a lot of source went too. More-detailed versions of the rumor (but no citation for the lawsuit, which should exist if it really happened, right?): http://www.winntmag.com/Windows/Article/ArticleID/4652/4652.html http://www.win2000mag.com/Articles/Print.cfm?ArticleID=7153 http://www.summitstrat.com/website/web2deliv.nsf/LOOKUP3/40506B455860E8748525657C0080D48C Dave Eckhardt ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:13 ` Skip Tavakkolian 2004-12-16 5:17 ` geoff @ 2004-12-16 5:23 ` Andy Newman 2004-12-16 15:52 ` Ronald G. Minnich 2 siblings, 0 replies; 69+ messages in thread From: Andy Newman @ 2004-12-16 5:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Skip Tavakkolian wrote: > Whatever happened to him? Where is he now? http://www.microsoft.com/presspass/exec/rick/default.asp ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 5:13 ` Skip Tavakkolian 2004-12-16 5:17 ` geoff 2004-12-16 5:23 ` Andy Newman @ 2004-12-16 15:52 ` Ronald G. Minnich 2 siblings, 0 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-16 15:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 15 Dec 2004, Skip Tavakkolian wrote: > Whatever happened to him? Where is he now? google ... Dr. Richard F. Rashid Senior Vice President Microsoft Research Updated: April 12, 2004 Currently charged with oversight of Microsoft Research’s worldwide operations, Richard (“Rick”) F. Rashid previously served as the director of Microsoft Research, focusing on operating systems, networking and multiprocessors. In that role he was responsible for managing work on key technologies leading to the development of Microsoft Corp.’s interactive TV system and authored a number of patents in areas such as data compression, networking and operating systems. In addition to running Microsoft Research, Rashid also was instrumental in creating the team that eventually became Microsoft’s Digital Media Division and directing Microsoft’s first e-commerce group. Rashid was promoted to vice president of Microsoft Research in 1994, and then to senior vice president in 2000. ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 0:24 ` geoff 2004-12-16 4:12 ` Ronald G. Minnich @ 2004-12-16 8:17 ` Martin C.Atkins 2004-12-16 9:35 ` jim 2004-12-16 15:19 ` rog 2004-12-16 9:30 ` jim 2004-12-16 15:08 ` David Leimbach 3 siblings, 2 replies; 69+ messages in thread From: Martin C.Atkins @ 2004-12-16 8:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi All, On Wed, 15 Dec 2004 16:24:47 -0800 geoff@collyer.net wrote: > OS X is in no sense a micro-kernel. The OS X kernel is huge: :-( >... > (through the ``type'' argument to mount) or pretend to be NFS servers. > I've never yet seen a (l)unix system other than late Research Unix > that made user-mode file servers relatively easy and painless to write > (though I'd love to be shown a counter-example!). Of course, since It's not so nice, in the sense that there is a fair amount (~1400 lines) of support code, but I've got a library that makes it quite nice from the filesystem writer's point of view. For example, mounting an ftp server takes ~180 lines of code. A test filesystem is <60 lines... BTW: all the code is Python (for better, for worse!), and it does NOT pretend to be an NFS server (yuk!). However, and this is a hint(!), the kernel agent is in the standard Linux distribution, and has been for years! It is also in several other OS distributions, but I haven't tried my library on them yet. Any guesses? I keep meaning to package it up, and release it - if there is any interest... > many (l)unix systems only allow the super-user to mount anything, > their maintainers may not see much utility in user-mode file servers. > It's sort of a cascade of vision-failures. Here, here! Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin} ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 8:17 ` Martin C.Atkins @ 2004-12-16 9:35 ` jim 2004-12-16 15:19 ` rog 1 sibling, 0 replies; 69+ messages in thread From: jim @ 2004-12-16 9:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 16 Dec 2004, at 08:17, Martin C.Atkins wrote: > > It's not so nice, in the sense that there is a fair amount (~1400 > lines) of support code, but I've got a library that makes it quite > nice from the filesystem writer's point of view. > w00. I'd like to have a look at that, if you don't mind. > For example, mounting an ftp server takes ~180 lines of code. A test > filesystem is <60 lines... > Excellent. Sod the support code; if it lets me do that, then it's perfect :-). > BTW: all the code is Python (for better, for worse!), and it does NOT wow. ;-) > pretend to be an NFS server (yuk!). However, and this is a hint(!), > the kernel agent is in the standard Linux distribution, and has been > for years! It is also in several other OS distributions, but I haven't > tried my library on them yet. Any guesses? > Some kind of ld_preloading of read and write? That's how I was going to do it, but I got lost in the hairiness ages ago. > I keep meaning to package it up, and release it - if there is any > interest... > Over here! Cheers, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 8:17 ` Martin C.Atkins 2004-12-16 9:35 ` jim @ 2004-12-16 15:19 ` rog 2004-12-16 15:26 ` jim 1 sibling, 1 reply; 69+ messages in thread From: rog @ 2004-12-16 15:19 UTC (permalink / raw) To: 9fans > BTW: all the code is Python (for better, for worse!), and it does NOT > pretend to be an NFS server (yuk!). However, and this is a hint(!), > the kernel agent is in the standard Linux distribution, and has been > for years! It is also in several other OS distributions, but I haven't > tried my library on them yet. Any guesses? goawn, tell us... we're all on tenterhooks! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 15:19 ` rog @ 2004-12-16 15:26 ` jim 0 siblings, 0 replies; 69+ messages in thread From: jim @ 2004-12-16 15:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 16 Dec 2004, at 15:19, rog@vitanuova.com wrote: >> BTW: all the code is Python (for better, for worse!), and it does NOT >> pretend to be an NFS server (yuk!). However, and this is a hint(!), >> the kernel agent is in the standard Linux distribution, and has been >> for years! It is also in several other OS distributions, but I haven't >> tried my library on them yet. Any guesses? > > goawn, tell us... we're all on tenterhooks! > I know I am... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 0:24 ` geoff 2004-12-16 4:12 ` Ronald G. Minnich 2004-12-16 8:17 ` Martin C.Atkins @ 2004-12-16 9:30 ` jim 2004-12-16 15:08 ` David Leimbach 3 siblings, 0 replies; 69+ messages in thread From: jim @ 2004-12-16 9:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 16 Dec 2004, at 00:24, geoff@collyer.net wrote: > OS X is in no sense a micro-kernel. The OS X kernel is huge: So I see. Much like NT being a 'micro-kernel' then? > Also, /sys/src/cmd/upas/README is a little dated: > > --rw-rw-r-- M 5174 sys sys 1041 Dec 11 1999 README > Ahh. > I'm not sure if it pre-dates upas/fs, but it describes how to port the > parts of upas that don't rely on Plan 9 facilities (transport more > than reading). I ported Plan 9's upas back to Unix while at the labs > (and also translated it into limbo), but some parts (e.g., upas/fs) > didn't have an obvious implementation, other than painfully pretending > to be an NFS server, at least at the time. > I see. The problem is in how to construct and present a filesystem on a unix with no user mounting system? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 0:24 ` geoff ` (2 preceding siblings ...) 2004-12-16 9:30 ` jim @ 2004-12-16 15:08 ` David Leimbach 2004-12-16 23:22 ` geoff 3 siblings, 1 reply; 69+ messages in thread From: David Leimbach @ 2004-12-16 15:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs hmmm not sure where this all came from on this thread of discussion :). On Wed, 15 Dec 2004 16:24:47 -0800, geoff@collyer.net <geoff@collyer.net> wrote: > OS X is in no sense a micro-kernel. The OS X kernel is huge: > > ; size /mach_kernel > __TEXT __DATA __OBJC others dec hex > 3022848 458752 0 643984 4125584 3ef390 > > and consists of a heavily-hacked Mach (3, I believe) kernel and a > FreeBSD kernel (with bits from other BSDs), combined into a single > kernel and running in a single address space. The BSD kernel does not > run in user mode. Remember that Mach was, as far as I know, the > largest ``micro-kernel'' ever produced, larger than most or all of its > contemporary ``macro-kernels'', so that some of us called it a > ``Machro-kernel''. It's an OSF Mach3 with "optimizations" :). The kernel is really nothing like FreeBSD. It's more like the BSD from NeXTStep with some Free/Open/Net BSD stuff hacked in. Also you are forgetting IOKit [the C++ framework for device drivers]. The Apple marketing team is just putting rubbish on the internet when it comes to claiming things are based on FreeBSD 5. In fairness, some of the userland applications and command line tools are, in fact, from FreeBSD but the amount of FreeBSD in XNU [the kernel] and Darwin is exaggerated. Porting things from FreeBSD 5, however to Mac OS X is quite painful because you have to deal with IOKit and the hardly FreeBSD-like bsd kernel portion. > > I haven't looked very hard (one could check out the mount_* sources > from the Darwin CVS servers), but mount(2) doesn't seem to have much > that's new, except for union mounts, which surprised me. I suspect > that most of the mount_* commands either invoke kernel machinery > (through the ``type'' argument to mount) or pretend to be NFS servers. > I've never yet seen a (l)unix system other than late Research Unix > that made user-mode file servers relatively easy and painless to write > (though I'd love to be shown a counter-example!). Of course, since > many (l)unix systems only allow the super-user to mount anything, > their maintainers may not see much utility in user-mode file servers. > It's sort of a cascade of vision-failures. Maybe because people don't know why Plan 9 is better than Unix they thing Unix is "the way". Religion often overrides common sense. Do we need more plan 9 "missionaries"? [probably] DragonflyBSD is working on making the VFS a message passing layer instead of a system call layer so doing something like 9p is probably already in their grand scheme of development. http://www.dragonflybsd.org/goals/vfsmodel.cgi This doesn't help Mac OS X of course. > > Also, /sys/src/cmd/upas/README is a little dated: > > --rw-rw-r-- M 5174 sys sys 1041 Dec 11 1999 README > > I'm not sure if it pre-dates upas/fs, but it describes how to port the > parts of upas that don't rely on Plan 9 facilities (transport more > than reading). I ported Plan 9's upas back to Unix while at the labs > (and also translated it into limbo), but some parts (e.g., upas/fs) > didn't have an obvious implementation, other than painfully pretending > to be an NFS server, at least at the time. > Might be interesting to see how DragonFlyBSD has come along and if it's possible to implement upas/fs with whatever they've done. Again this doesn't really help Mac OS X. I just think it's interesting. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 15:08 ` David Leimbach @ 2004-12-16 23:22 ` geoff 2004-12-16 23:25 ` boyd, rounin ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: geoff @ 2004-12-16 23:22 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 2028 bytes --] I worked at Apple in the BSD group. The XNU non-Mach code was clearly some BSD kernel and I don't really care which. My colleagues told me it started out with NetBSD but that that was eventually dwarfed by FreeBSD with contributions from elsewhere. While I was there, there was talk of dragging in code from the latest FreeBSD, notably the FFS with soft updates; I'm pretty sure that happened. Given that the group was (and probably still is) headed by Jordan Hubbard of FreeBSD fame, I suspect that they're continuing to pull in FreeBSD code and it isn't just hype. Note too that the XNU BSD code, measured in source lines, is almost exactly as huge as the Mach code, so the volume of *BSD code in XNU is not, in my opinion, exaggerated: it is (or was in 2002) half the kernel source. (I don't remember which side of the fence IOKit was counted against.) Yes, the XNU kernel details are different from a stock BSD kernel. It co-exists with Mach, after all. Porting graphical applications to native OS X (avoiding X11) is a pain too; Apple do a lot of things their own way, inheriting baggage from the pre-Unix Mac OS and NextStep (netinfo is just the French spelling of `Yellow Pages', ugh). Nevertheless, I stand by my statement that OS X is in no sense a micro-kernel, and that user-mode file servers will not (as a result of access to a micro-kernel) be easier to implement on OS X than on other (l)unixes. However, Martin Atkins has revealed the mystery kernel agent: coda. Apparently it's somewhat specialised but lets user-mode file servers catch opens and closes. Anyone in (l)unixland for a filesystem switch? Research Unix had one ~20 years ago, so it should be mouldy (er, mature) enough to be acceptable to (l)unixland. Throw in mounts by ordinary users and use of 9P as an unifying filesystem protocol (now pretty well aged in Plan 9), and it becomes possible to push lots of code and some hacks out of the kernel, while permitting some new and interesting work. [-- Attachment #2: Type: message/rfc822, Size: 6546 bytes --] From: David Leimbach <leimy2k@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Acme mailreader Date: Thu, 16 Dec 2004 07:08:34 -0800 Message-ID: <3e1162e6041216070874f424e5@mail.gmail.com> hmmm not sure where this all came from on this thread of discussion :). On Wed, 15 Dec 2004 16:24:47 -0800, geoff@collyer.net <geoff@collyer.net> wrote: > OS X is in no sense a micro-kernel. The OS X kernel is huge: > > ; size /mach_kernel > __TEXT __DATA __OBJC others dec hex > 3022848 458752 0 643984 4125584 3ef390 > > and consists of a heavily-hacked Mach (3, I believe) kernel and a > FreeBSD kernel (with bits from other BSDs), combined into a single > kernel and running in a single address space. The BSD kernel does not > run in user mode. Remember that Mach was, as far as I know, the > largest ``micro-kernel'' ever produced, larger than most or all of its > contemporary ``macro-kernels'', so that some of us called it a > ``Machro-kernel''. It's an OSF Mach3 with "optimizations" :). The kernel is really nothing like FreeBSD. It's more like the BSD from NeXTStep with some Free/Open/Net BSD stuff hacked in. Also you are forgetting IOKit [the C++ framework for device drivers]. The Apple marketing team is just putting rubbish on the internet when it comes to claiming things are based on FreeBSD 5. In fairness, some of the userland applications and command line tools are, in fact, from FreeBSD but the amount of FreeBSD in XNU [the kernel] and Darwin is exaggerated. Porting things from FreeBSD 5, however to Mac OS X is quite painful because you have to deal with IOKit and the hardly FreeBSD-like bsd kernel portion. > > I haven't looked very hard (one could check out the mount_* sources > from the Darwin CVS servers), but mount(2) doesn't seem to have much > that's new, except for union mounts, which surprised me. I suspect > that most of the mount_* commands either invoke kernel machinery > (through the ``type'' argument to mount) or pretend to be NFS servers. > I've never yet seen a (l)unix system other than late Research Unix > that made user-mode file servers relatively easy and painless to write > (though I'd love to be shown a counter-example!). Of course, since > many (l)unix systems only allow the super-user to mount anything, > their maintainers may not see much utility in user-mode file servers. > It's sort of a cascade of vision-failures. Maybe because people don't know why Plan 9 is better than Unix they thing Unix is "the way". Religion often overrides common sense. Do we need more plan 9 "missionaries"? [probably] DragonflyBSD is working on making the VFS a message passing layer instead of a system call layer so doing something like 9p is probably already in their grand scheme of development. http://www.dragonflybsd.org/goals/vfsmodel.cgi This doesn't help Mac OS X of course. > > Also, /sys/src/cmd/upas/README is a little dated: > > --rw-rw-r-- M 5174 sys sys 1041 Dec 11 1999 README > > I'm not sure if it pre-dates upas/fs, but it describes how to port the > parts of upas that don't rely on Plan 9 facilities (transport more > than reading). I ported Plan 9's upas back to Unix while at the labs > (and also translated it into limbo), but some parts (e.g., upas/fs) > didn't have an obvious implementation, other than painfully pretending > to be an NFS server, at least at the time. > Might be interesting to see how DragonFlyBSD has come along and if it's possible to implement upas/fs with whatever they've done. Again this doesn't really help Mac OS X. I just think it's interesting. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 23:22 ` geoff @ 2004-12-16 23:25 ` boyd, rounin 2004-12-16 23:38 ` Ronald G. Minnich ` (2 subsequent siblings) 3 siblings, 0 replies; 69+ messages in thread From: boyd, rounin @ 2004-12-16 23:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Anyone in (l)unixland for a filesystem switch? ULTRIX had user mode NFS mounts/servers -- nasty. > Research Unix had one ~20 years ago ... sure did ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 23:22 ` geoff 2004-12-16 23:25 ` boyd, rounin @ 2004-12-16 23:38 ` Ronald G. Minnich 2004-12-17 1:31 ` Skip Tavakkolian 2004-12-17 4:55 ` [9fans] Acme mailreader - now: User mode filesystems in linux Martin C.Atkins 2004-12-17 18:52 ` [9fans] Acme mailreader David Leimbach 3 siblings, 1 reply; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-16 23:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 16 Dec 2004 geoff@collyer.net wrote: > However, Martin Atkins has revealed the mystery kernel agent: coda. you could also use the intermezzo module for that type of thing, and it's a bit smaller. ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 23:38 ` Ronald G. Minnich @ 2004-12-17 1:31 ` Skip Tavakkolian 2004-12-17 15:50 ` Ronald G. Minnich 0 siblings, 1 reply; 69+ messages in thread From: Skip Tavakkolian @ 2004-12-17 1:31 UTC (permalink / raw) To: 9fans >> However, Martin Atkins has revealed the mystery kernel agent: coda. > > you could also use the intermezzo module for that type of thing, and it's > a bit smaller. but what's under coda, AFS or intermezzo? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-17 1:31 ` Skip Tavakkolian @ 2004-12-17 15:50 ` Ronald G. Minnich 0 siblings, 0 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-17 15:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 16 Dec 2004, Skip Tavakkolian wrote: > but what's under coda, AFS or intermezzo? as martin explained better than I had, intermezzo (Presotto can translate except he has left the building) is 'something between 2 things' and in this case it is an interposition between the top of VFS and ext[2,3]. When the VFS layer does I/O imezzo decides whether to kick the request out to userspace or satisfy it with the ext3 store. the userspace daemon can invalidate entries in the 'cache' (ext3 store). It gets complex and you can see how much easier plan 9 makes this stuff, but that's basically it. ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-16 23:22 ` geoff 2004-12-16 23:25 ` boyd, rounin 2004-12-16 23:38 ` Ronald G. Minnich @ 2004-12-17 4:55 ` Martin C.Atkins 2004-12-17 9:54 ` Martin C.Atkins 2004-12-17 15:44 ` Ronald G. Minnich 2004-12-17 18:52 ` [9fans] Acme mailreader David Leimbach 3 siblings, 2 replies; 69+ messages in thread From: Martin C.Atkins @ 2004-12-17 4:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi all, On Thu, 16 Dec 2004 15:22:59 -0800 geoff@collyer.net wrote: >.. > However, Martin Atkins has revealed the mystery kernel agent: coda. > Apparently it's somewhat specialised but lets user-mode file servers > catch opens and closes. I was going to write a longer message today, anyway :-). Yes, the kernel-mode agent I use is the Coda filesystem driver, which has been in the stock linux kernel for several years. For those that don't already know: Coda is a remote filesystem that copes (more or less well) with disconnection from, and reconnection to the fileserver. Thus allowing clients to continue work in the disconnected state. I'm not sure how successful it was at this - I've never tried it - but it sounds like an interesting goal. This goal is also shared by Intermezzo, which was (also) started by Peter Braam - so presumably he felt Coda could be improved upon. However, judging by the News pages on their web sites, more seems to be happening with Coda, than with Intermezzo, recently. Anyway, the interesting thing about both these systems, from the point of view of this discussion, is that the real work is done in a user-mode agent, which communicates with a kernel-mode stub driver. In Coda the user-mode agent is, for some obscure reason, called Venus. Thus it was only necessary to reverse-engineer the kernel module <-> Venus protocol. This was surprisingly easy: it is documented in some detail on the Coda website, and Pavel Machek's podfuk had already worked out some of the more obscure details (but this wasn't a general-purpose library, didn't do some things I wanted, and was I thought, messy). The Coda driver is stable enough that I don't remember any hangs/etc, even while I was going through the trial-and-error process! The user-mode agent simply opens /dev/cfsN, for some N, and reads and writes messages down to the kernel module. My library for this is, as I said, about 1400 lines of Python. Trivial fileserver applications can be as small as 10-20 lines, and faulty fileservers (or library) never crash/hang the kernel (which is how things should be! :-). It is also possible to kill the fileserver, and restart with minimal side effects. It would be easy to make libraries for other languages. One curiosity, which is both an advantage, and a disadvantage depending on what you want to do: The user-mode agent is not involved in - does not even see - reads and writes. When a client opens a file, the user-mode agent makes a file somewhere containing the contents of the "virtual" file, opens it, and writes the file descriptor down into the kernel. The kernel module returns this file descriptor (more or less) to the client who reads and writes it as a normal file, with no intervention of Coda. When the client closes the file, the kernel driver tells the user-mode agent, which deals with the (possibly new) contents of the file, and might then remove it from the local filesystem. The advantage of this is that reads/writes happen at the same speed as reads and writes to local files. The disadvantages are that the open has to make a local copy of the entire contents of the file - even if it is very big - and can't process individual writes as commands, as in common in Plan 9. The user-mode agent might also have to read the file to work out what changed. However, you can rather easily process open+write+close as a command to the user-mode agent, or have a file whose contents are different every time it is opened. (So you do open+read+close, to read a status value, for example) Ideally, I'd like the processing of open to be able to decide whether to send a file descriptor down into the kernel, or to receive read/write messages - this seems to have been in previous versions of Coda - such is life! Re: Intermezzo - as Ron pointed out, it's kernel driver could also possibly be used for this purpose. However, it uses hooks into an underlying journalled filessystem - a requirement that I couldn't easily satisfy back when I started this work, and I wasn't sure that the kernel-user space interface was so easy to apply to my purpose. However, it might allow one to avoid the disadvantages mentioned in the last paragraph. I've been meaning to opensource the library for a while now - but I'd like to clean it up in a few places, before a proper release. This interest might be the spur to make me get around to it... >... > 9), and it becomes possible to push lots of code and some hacks out of > the kernel, while permitting some new and interesting work. No disagreements there! Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin} ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 4:55 ` [9fans] Acme mailreader - now: User mode filesystems in linux Martin C.Atkins @ 2004-12-17 9:54 ` Martin C.Atkins 2004-12-17 10:22 ` geoff ` (3 more replies) 2004-12-17 15:44 ` Ronald G. Minnich 1 sibling, 4 replies; 69+ messages in thread From: Martin C.Atkins @ 2004-12-17 9:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Of course, nothing I wrote in the previous message avoids (l)unix's limitations regarding mount, etc. Nor does it allow users to write their own fileservers (without opening up various security holes, and having root access). However, thinking over lunch, I realised that there is a way of doing something quite nice (in the linux sense, if not the Plan 9 sense!) with what we already have. On login, each user starts a user-filesystem-daemon, which uses setuid to create a /dev/cfsN, if necessary, opens it to start serving, and mounts it on a conventional place: $HOME/mnt, say. When the user runs a program that wants to serve a filesystem, it attaches to the daemon, which creates $HOME/mnt/servicename, and forwards all requests for this directory hierarchy to the program. Replies are adjusted to be consistent with security - setuid bits removed, ownership forced to the user, etc., and sent back to the kernel. When the program terminates, the daemon cleans up, and removes servicename. Advantages over just hacking mount to allow anyone to mount anything on $HOME/mnt: 1) We don't need a /dev/cfsN for every filesystem, just one for each concurrent user. Also client fileserving programs don't have to compete to allocate /dev/cfsN's - which would need some sort of setuid - only the daemons do this. 2) The user-filesystem-daemon only has to run as root during initialisation, everything else runs as the user. 3) The user-filesystem-daemon can enforce file ownership (as the user) in the served directory hierarchy. It can also force off setuid bits, etc. Furthermore, users can only attach their fileservers to their own daemons! (A bit like per-process mount tables - of course, linux has this already, but not in a very user-friendly form) 4) The user-filesystem-daemon can clean up when/if a fileserver crashes. 5) Knowledge of the Coda protocol could be limited to the daemon, and a higher-level protocol used with the "real" fileservers. Thus we could move to other kernel mechanisms (e.g. fuse) if/when they become available. 6) All user filesystems are under $HOME/mnt - symlinks could be used from elsewhere. (or is this a disadvantage?) Disadvantages: 1) greater overhead - each fileserving message has to make the extra hops from daemon to fileserver program, and back. 2) Complexity? 3) Others...? The same approach would probably also work (better, easier?) with p9fs - but some of the advantages might already have been solved there, in other ways. What do people think? Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin} ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 9:54 ` Martin C.Atkins @ 2004-12-17 10:22 ` geoff 2004-12-17 10:45 ` Martin C.Atkins ` (3 more replies) 2004-12-17 13:41 ` Derek Fawcus ` (2 subsequent siblings) 3 siblings, 4 replies; 69+ messages in thread From: geoff @ 2004-12-17 10:22 UTC (permalink / raw) To: 9fans Someone at the 9bof claimed that at least one of the BSDs already permits users to mount things on any directory for which they have write permission. I suspect that the policy actually needs to be a little stricter than that; you don't want people mounting (system-wide) on /tmp. Perhaps any directory that you own would make more sense. But we also heard that the maintainers of at least one of the other BSDs or Linux have a religious aversion to users mounting anything. Certainly one would want to think through the interactions of set-id and user mounts. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 10:22 ` geoff @ 2004-12-17 10:45 ` Martin C.Atkins 2004-12-17 11:42 ` Andy Newman ` (2 subsequent siblings) 3 siblings, 0 replies; 69+ messages in thread From: Martin C.Atkins @ 2004-12-17 10:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004 02:22:22 -0800 geoff@collyer.net wrote: > ... But we also heard that the maintainers of at least one of > the other BSDs or Linux have a religious aversion to users mounting > anything. ... What was it you called it?... "a cascade of vision-failures." Very apt. Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin} ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 10:22 ` geoff 2004-12-17 10:45 ` Martin C.Atkins @ 2004-12-17 11:42 ` Andy Newman 2004-12-17 15:57 ` Ronald G. Minnich 2004-12-17 12:30 ` Latchesar Ionkov 2004-12-17 15:55 ` Ronald G. Minnich 3 siblings, 1 reply; 69+ messages in thread From: Andy Newman @ 2004-12-17 11:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs geoff@collyer.net wrote: > Someone at the 9bof claimed that at least one of the BSDs already > permits users to mount things FreeBSD does, don't know about the others. > Perhaps any directory that you own would make more sense. Comments taken from mount (in vfs_syscalls.c)... /* * If the user is not root, ensure that they own the directory * onto which we are attempting to mount. */ > Certainly one would want to think through the interactions > of set-id and user mounts. /* * Silently enforce MNT_NOSUID and MNT_NODEV for non-root users */ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 11:42 ` Andy Newman @ 2004-12-17 15:57 ` Ronald G. Minnich 0 siblings, 0 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-17 15:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004, Andy Newman wrote: > > Certainly one would want to think through the interactions > > of set-id and user mounts. > > /* > * Silently enforce MNT_NOSUID and MNT_NODEV for non-root users > */ that's what I did on 2.0.36, and the fact that you could not express the suid and other such nasty bits in the attributes of a 9p file made it pretyt easy to do that :-) ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 10:22 ` geoff 2004-12-17 10:45 ` Martin C.Atkins 2004-12-17 11:42 ` Andy Newman @ 2004-12-17 12:30 ` Latchesar Ionkov 2004-12-17 15:55 ` Ronald G. Minnich 3 siblings, 0 replies; 69+ messages in thread From: Latchesar Ionkov @ 2004-12-17 12:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs If you combine the restriction for mounting filesystems only on directories you have write access to, with the (enforced) creation of private namespace that Linux allows, mounting on /tmp is not a problem anymore. Lucho On Fri, Dec 17, 2004 at 02:22:22AM -0800, geoff@collyer.net said: > Someone at the 9bof claimed that at least one of the BSDs already > permits users to mount things on any directory for which they have > write permission. I suspect that the policy actually needs to be a > little stricter than that; you don't want people mounting > (system-wide) on /tmp. Perhaps any directory that you own would make > more sense. But we also heard that the maintainers of at least one of > the other BSDs or Linux have a religious aversion to users mounting > anything. Certainly one would want to think through the interactions > of set-id and user mounts. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 10:22 ` geoff ` (2 preceding siblings ...) 2004-12-17 12:30 ` Latchesar Ionkov @ 2004-12-17 15:55 ` Ronald G. Minnich 3 siblings, 0 replies; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-17 15:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004 geoff@collyer.net wrote: > Someone at the 9bof claimed that at least one of the BSDs already > permits users to mount things on any directory for which they have > write permission. Russ Cox mentioned that NetBSD (??) allows you to mount on a directory you own. You have to own it. Still lotsa danger here. Linux has a religious aversion to users mounting things, and has since at least 1996 when I started asking them about this for a very early version of v9fs. They did not object to v9fs per se, just the concept of user mounts! ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 9:54 ` Martin C.Atkins 2004-12-17 10:22 ` geoff @ 2004-12-17 13:41 ` Derek Fawcus 2004-12-17 14:42 ` Karl Magdsick 2004-12-18 0:13 ` Tim Newsham 3 siblings, 0 replies; 69+ messages in thread From: Derek Fawcus @ 2004-12-17 13:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Dec 17, 2004 at 03:24:56PM +0530, Martin C.Atkins wrote: > 2) The user-filesystem-daemon only has to run as root during initialisation, > everything else runs as the user. > > 3) The user-filesystem-daemon can enforce file ownership (as the user) in > the served directory hierarchy. It can also force off setuid bits, etc. > Furthermore, users can only attach their fileservers to their own daemons! > (A bit like per-process mount tables - of course, linux has this already, but > not in a very user-friendly form) So while it's running, I can use gdb to attach to it and get around any security it's trying to enforce (turn setuid back on, change ownership to root, etc). DF ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 9:54 ` Martin C.Atkins 2004-12-17 10:22 ` geoff 2004-12-17 13:41 ` Derek Fawcus @ 2004-12-17 14:42 ` Karl Magdsick 2004-12-17 14:56 ` Russ Cox 2004-12-18 0:13 ` Tim Newsham 3 siblings, 1 reply; 69+ messages in thread From: Karl Magdsick @ 2004-12-17 14:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > On login, each user starts a user-filesystem-daemon, which uses setuid > to create a /dev/cfsN, if necessary, opens it to start serving, and > mounts it on a conventional place: $HOME/mnt, say. Why are the setuid meta-daemons needed? You'll want security/sanity checks within the kernel code anyway, so the main reason for the setuid meta-daemons is creating(??/destroying??) device files. It seems that you could get around this by using one device file for everyone, which brings us to... Why N different devices? The kernel can distinguish between open filehandles for /dev/cfs and use an array, tree, or map of structs to keep track of which file handle goes with which mount point. (Yay, flyweight design pattern!) This prevents nastiness with trying to find an unused device, creating devices on demand, and "garbage collecting" unused device files. (You wouldn't want a trillion unused devices sitting around.) The kernel can free associated structs when filehandles close. Having the meta-daemons garbage collecting unused device files seems like trouble. > When the user runs a program that wants to serve a filesystem, it attaches to > the daemon, which creates $HOME/mnt/servicename, and forwards all > requests for this directory hierarchy to the program. As mentioned in another post, you can prevent device files and setuid executibles in non-root owned filesystems and allow any user process to mount a fs on any mount point they own. The kernel needs its own cleanup code (what if one of the per-user filesystem meta-daemons crashes?) and security/sanity checks (only allowing root-owned processes to open filehandles to the device). Granted, using a map of N structs and 1 device instead of N devices each with 1 struct does increase kernel complexity, but only by a small amount. The kernel needs its own security/sanity checks and cleanup code even in the case of per-user setuid filesystem meta-daemons. Setuid per-user filesystem meta-daemons seem like they would greatly increase user-space complexity (and duplicate functionality that MUST also be in the kernel) and only minimally reduce kernel complexity. Don't get me wrong, I'm a big fan of micro/nanokernels. I dual booted BeOS 5 and L4-Linux on my desktop, back when the latest port to L4 user-space was Linux 2.2.(??20??). I got a warm fuzzy feeling every time my BeOS flakey 3Com NIC driver crashed and BeOS asked me if I wanted to restart the network driver. Buggy drivers weren't so fun, but a system that easily recovers from driver crashes is just cool! (I had a UDFS CD that would cause fs driver crashes in both Linux (kernel panic) and Win2k (BSOD). I really wished for user-space fs drivers on "normal" systems.) After a few days of 2 L4-Linux system lock-ups per day, I went back to using Linux as a regular kernel. (The diagnostic counters kept spinning, so it seemed that the Linux server had locked up, not L4, but all of my processes depended on the Linux server anyway.) In any case, I'd love to see user-space filesystem (and device) drivers on mainstream OSes. I don't have much knowledge of/experience with Plan9, but I've read that the system is designed so that it's very easy to port drivers between user-space and kernel-space. Is this correct? In a "standard" setup, how many of the drivers are (mostly) in user-space? -Karl ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 14:42 ` Karl Magdsick @ 2004-12-17 14:56 ` Russ Cox 0 siblings, 0 replies; 69+ messages in thread From: Russ Cox @ 2004-12-17 14:56 UTC (permalink / raw) To: Karl Magdsick, Fans of the OS Plan 9 from Bell Labs > [Lots of good arguments] You're stuck with the operating system you have, not the operating system you'd like to have. If one were designing the system from scratch one could always do better. Sadly this Coda discussion is about how to deal with what's already available on Unix. > I don't have much knowledge of/experience with Plan9, but I've read > that the system is designed so that it's very easy to port drivers > between user-space and kernel-space. Is this correct? No, it's not. It's not hard (I can't think of any system-level programming task I'd characterize as "hard" using Plan 9) but it's not trivial either. > In a "standard" setup, how many of the drivers are (mostly) in user-space? Anything that touches hardware is typically in the kernel, though in the case of particularly complicated hardware (like vga and usb), the kernel part just makes it possible for user-mode programs to get at the hardware and do the complicated stuff. On the other hand, file system drivers are typically outside the kernel, and the network and graphics devices have moved back and forth a few times. Russ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 9:54 ` Martin C.Atkins ` (2 preceding siblings ...) 2004-12-17 14:42 ` Karl Magdsick @ 2004-12-18 0:13 ` Tim Newsham 2004-12-18 0:13 ` boyd, rounin 3 siblings, 1 reply; 69+ messages in thread From: Tim Newsham @ 2004-12-18 0:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > However, thinking over lunch, I realised that there is a way of doing > something quite nice (in the linux sense, if not the Plan 9 sense!) with > what we already have. > > On login, each user starts a user-filesystem-daemon, which uses setuid > to create a /dev/cfsN, if necessary, opens it to start serving, and > mounts it on a conventional place: $HOME/mnt, say. [...] I think it would be better to just implement the v9fs protocol and let users mount it in a similar way as nfs. The v9fs layer in the kernel would simply communicate the kernel filesystem requests over some pipe to another machine (or the same machine) in much the same way as nfs requests get sent out. The layer could support options (or strictly enforce) to disable setuid bits and/or file ownership. A setuid mounting utility that enforced any no-setuid options could allow users to perform mounts. Userland filesystems could be implemented by providing a service that adheres to the v9fs. Adding a seperate userland demon that proxies a filesystem protocol (probably the same one) through to the kernel seems like an uneeded layer of complexity. It seems like there are a lot of projects out there that have interest in providing userland filesystems. They typically use nfs because its the easiest vector into the existing infrastructure. V9fs would definitely fill a useful niche. > 2) The user-filesystem-daemon only has to run as root during initialisation, > everything else runs as the user. A network daemon talking v9fs shouldn't impose any ownership restrictions. The restrictions should be imposed at mount time. > 3) The user-filesystem-daemon can enforce file ownership (as the user) in > the served directory hierarchy. It can also force off setuid bits, etc. > Furthermore, users can only attach their fileservers to their own daemons! > (A bit like per-process mount tables - of course, linux has this already, but > not in a very user-friendly form) This can be done in-kernel. In fact, there are already options in nfs to neuter suid bits, device nodes and provide user mappings. > 5) Knowledge of the Coda protocol could be limited to the daemon, and a > higher-level protocol used with the "real" fileservers. Thus we could move to > other kernel mechanisms (e.g. fuse) if/when they become available. V9fs already provides a useful protocol. > 6) All user filesystems are under $HOME/mnt - symlinks could be used > from elsewhere. (or is this a disadvantage?) Restrictions as to where mount points could be placed could be put in any setuid binary that mediates user mounts. Tim N. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-18 0:13 ` Tim Newsham @ 2004-12-18 0:13 ` boyd, rounin 2004-12-18 3:49 ` Ronald G. Minnich 0 siblings, 1 reply; 69+ messages in thread From: boyd, rounin @ 2004-12-18 0:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I think it would be better to just implement the v9fs protocol > and let users mount it in a similar way as nfs. been there, done that. nfs is no fun. you have to get right up into the vfs layer. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-18 0:13 ` boyd, rounin @ 2004-12-18 3:49 ` Ronald G. Minnich 2004-12-23 16:04 ` boyd, rounin 0 siblings, 1 reply; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-18 3:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, 18 Dec 2004, boyd, rounin wrote: > > I think it would be better to just implement the v9fs protocol > > and let users mount it in a similar way as nfs. > > been there, done that. nfs is no fun. you have to get right up into > the vfs layer. ah, boyd, you gotta read what he's saying cause it's what we want. All Tim is saying is "let's just go 9p2000 from Linux VFS layer to userland servers". This is good. And since v9fs does that, and it's basically there on 2.6, it's the right way to go. ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-18 3:49 ` Ronald G. Minnich @ 2004-12-23 16:04 ` boyd, rounin 0 siblings, 0 replies; 69+ messages in thread From: boyd, rounin @ 2004-12-23 16:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > ah, boyd, you gotta read what he's saying cause it's what we want. that's what i meant. i wasn't being explicit enough. if you stick into the VFS (which i looked at once for the ULTRIX GFS, but it was too horrible) then everything is cool. btw: in brussels on my way back from Twente. gotta find me a prepaid WiFi login. i have some photos i'll stick 'em up some point. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 4:55 ` [9fans] Acme mailreader - now: User mode filesystems in linux Martin C.Atkins 2004-12-17 9:54 ` Martin C.Atkins @ 2004-12-17 15:44 ` Ronald G. Minnich 2004-12-18 12:35 ` Martin C.Atkins 1 sibling, 1 reply; 69+ messages in thread From: Ronald G. Minnich @ 2004-12-17 15:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004, Martin C.Atkins wrote: > > For those that don't already know: Coda is a remote filesystem that > copes (more or less well) with disconnection from, and reconnection > to the fileserver. Thus allowing clients to continue work in the > disconnected state. I'm not sure how successful it was at this - I've > never tried it - but it sounds like an interesting goal. This goal is > also shared by Intermezzo, which was (also) started by Peter Braam - > so presumably he felt Coda could be improved upon. As peter used to put it, 5KLOC (intermezzo) was in his mind better than 500KLOC (coda). He brought both file systems to fruition. > However, judging by the News pages on their web sites, more seems to > be happening with Coda, than with Intermezzo, recently. yeah, intermezzo limped along for 5 years, never quite worked, then died. But the kernel->user interface of intermezzo is perfectly usable. Sounds like you've gotten far with coda, so this is just an FYI. I only know a bit about this because I did a lot of work with imezzo early in the game, and got to the point where I could boot a linux node with imezzo as the root file system. That was interesting. ron ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader - now: User mode filesystems in linux 2004-12-17 15:44 ` Ronald G. Minnich @ 2004-12-18 12:35 ` Martin C.Atkins 0 siblings, 0 replies; 69+ messages in thread From: Martin C.Atkins @ 2004-12-18 12:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Gosh - lots of comments.. On Fri, 17 Dec 2004 08:44:52 -0700 (MST) "Ronald G. Minnich" <rminnich@lanl.gov> wrote: > > so presumably he felt Coda could be improved upon. > > As peter used to put it, 5KLOC (intermezzo) was in his mind better than > 500KLOC (coda). He brought both file systems to fruition. Good reason! But the kernel modules were only a small fraction of that total size, right? > yeah, intermezzo limped along for 5 years, never quite worked, then died. > But the kernel->user interface of intermezzo is perfectly usable. Sounds > like you've gotten far with coda, so this is just an FYI. Pity abut Intermezzo - trying it (for it's designed purpose) was on my todo list... Thanks for your assessment of the Intermezzo kernal->user interface. I've often wondered if I could have been used it for my driver itstead of coda, but like you say, I've gotten thus far with Coda... > in the game, and got to the point where I could boot a linux node with > imezzo as the root file system. That was interesting. Sounds fun! On Fri, 17 Dec 2004 13:41:09 +0000 Derek Fawcus <dfawcus@cisco.com> wrote: > > 3) The user-filesystem-daemon can enforce file ownership (as the user) in > > the served directory hierarchy. It can also force off setuid bits, etc. > > Furthermore, users can only attach their fileservers to their own daemons! > > (A bit like per-process mount tables - of course, linux has this already, but > > not in a very user-friendly form) > > So while it's running, I can use gdb to attach to it and get around any security > it's trying to enforce (turn setuid back on, change ownership to root, etc). Good point! I guess it would have to stay setuid to avoid that - pity. Is there another way of stopping gdb, et al? I see that EPERM on ptrace can be caused if the debuggee is already being debugged. Is there any way that a program can ptrace itself, just to stop anyone else from debugging it? (1/2 :-)) On Fri, 17 Dec 2004 09:42:15 -0500 Karl Magdsick <kmagnum@gmail.com> wrote: > > On login, each user starts a user-filesystem-daemon, which uses setuid > > to create a /dev/cfsN, if necessary, opens it to start serving, and > > mounts it on a conventional place: $HOME/mnt, say. > > Why are the setuid meta-daemons needed? You'll want security/sanity > checks within the kernel code anyway, so the main reason for the > setuid meta-daemons is creating(??/destroying??) device files. It > seems that you could get around this by using one device file for > everyone, which brings us to... > > Why N different devices? The kernel can distinguish between open > filehandles for /dev/cfs and use an array, tree, or map of structs to > [ plus more good points] Two reasons: 1) I was trying to see how far we could get without having to change *anything* in the stock linux kernel distribution. This makes distributing the result much easier... 2) When you mount a coda device, you are talking to the fileserver that opened that coda device. If you multiplexed the device, you would have to have some other way of saying *which* user-mode fileserver you were trying to mount. Otherwise, I agree. > As mentioned in another post, you can prevent device files and setuid > executibles in non-root owned filesystems and allow any user process > to mount a fs on any mount point they own. Yes, and these mechanisms are [probably best. > The kernel needs its own cleanup code (what if one of the per-user > filesystem meta-daemons crashes?) and security/sanity checks (only If the per-user filesystem meta-daemons crashes, then, like I said, with coda, the kernel is pretty safe already. However I'd like the user's view of things to be cleaned up too. and: On Fri, 17 Dec 2004 14:13:35 -1000 (HST) Tim Newsham <newsham@lava.net> wrote: > I think it would be better to just implement the v9fs protocol > and let users mount it in a similar way as nfs. The v9fs layer In the future, I totally agree. Unfortunately my requirement was for something that would work with all the linux systems already out there. > Adding a seperate userland demon that proxies a filesystem > protocol (probably the same one) through to the kernel seems > like an uneeded layer of complexity. So it now seems - I was just thinking aloud, and the result was interesting, and informative for me. > It seems like there are a lot of projects out there that have > interest in providing userland filesystems. They typically use > nfs because its the easiest vector into the existing infrastructure. > V9fs would definitely fill a useful niche. Yes. The lack of close messages (until recently) in nfs, certainly restricted its usefulness for this purpose though. > V9fs already provides a useful protocol. No disagreements there, however there have already been discussions in other threads pointing out that V9fs doesn't (yet?) have messages for linux things that Plan 9 doesn't have - such as symlinks. > Restrictions as to where mount points could be placed could be > put in any setuid binary that mediates user mounts. I was trying to get around the restriction that user mounts could only be under $HOME/mnt, imposed by my scheme. Given access to a more general mount, I don't see any reason to restrict it unnecessarily! Thanks all for interesting feedback! Martin -- Martin C. Atkins martin_ml@parvat.com Parvat Infotech Private Limited http://www.parvat.com{/,/martin} ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-16 23:22 ` geoff ` (2 preceding siblings ...) 2004-12-17 4:55 ` [9fans] Acme mailreader - now: User mode filesystems in linux Martin C.Atkins @ 2004-12-17 18:52 ` David Leimbach 2004-12-17 23:20 ` Jack Johnson 3 siblings, 1 reply; 69+ messages in thread From: David Leimbach @ 2004-12-17 18:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 16 Dec 2004 15:22:59 -0800, geoff@collyer.net <geoff@collyer.net> wrote: > I worked at Apple in the BSD group. > > The XNU non-Mach code was clearly some BSD kernel and I don't really > care which. My colleagues told me it started out with NetBSD but that > that was eventually dwarfed by FreeBSD with contributions from > elsewhere. While I was there, there was talk of dragging in code from > the latest FreeBSD, notably the FFS with soft updates; I'm pretty sure > that happened. Given that the group was (and probably still is) > headed by Jordan Hubbard of FreeBSD fame, I suspect that they're > continuing to pull in FreeBSD code and it isn't just hype. > Mac OS X still doesn't have softupdates. I know because I took a crack at integrating them from OpenDarwin and was in sync with some other guys looking at it too. I also use Mac OS X pretty much every day of the week and spend most of my time developing on it. What they do have is VFS level journaling now and HFS+ takes advantage of it. There are things like kernel queues [terribly broken implementation of them in Panther. I can panic a box with them very reliably] from FBSD but some stuff just can't be easily ported from FBSD 5 due to the heavy reliance on mach for VM and scheduling. This is one of the most accurate sources of Mac OS X overviews I've seen: http://www.kernelthread.com/mac/osx/ > Note too that the XNU BSD code, measured in source lines, is almost > exactly as huge as the Mach code, so the volume of *BSD code in XNU is > not, in my opinion, exaggerated: it is (or was in 2002) half the > kernel source. (I don't remember which side of the fence IOKit was > counted against.) That sounds about right to me :). I've not played around in xnu in any serious way for a couple of months or years or so. > > Nevertheless, I stand by my statement that OS X is in no sense a > micro-kernel, and that user-mode file servers will not (as a result of > access to a micro-kernel) be easier to implement on OS X than on other > (l)unixes. Mac OS X is not a microkernel architecture... but it does "have a microkernel" :). I've seen kernel extensions that communicate with userland via mach_ports for process death notifications and other weird stuff like that. People have said that Mac OS X's ftpfs is done in userspace but since it's not open source there is no way for me to verify that. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-17 18:52 ` [9fans] Acme mailreader David Leimbach @ 2004-12-17 23:20 ` Jack Johnson 2004-12-18 1:00 ` David Leimbach 0 siblings, 1 reply; 69+ messages in thread From: Jack Johnson @ 2004-12-17 23:20 UTC (permalink / raw) To: David Leimbach, Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004 10:52:51 -0800, David Leimbach <leimy2k@gmail.com> wrote: > Mac OS X is not a microkernel architecture... but it does "have a > microkernel" :). I wonder how much of this is just NeXT heritage rather than purposefully to make the actual work of building/upgrading OS X any easier (or any other potentially valid reason)? -Jack ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-17 23:20 ` Jack Johnson @ 2004-12-18 1:00 ` David Leimbach 0 siblings, 0 replies; 69+ messages in thread From: David Leimbach @ 2004-12-18 1:00 UTC (permalink / raw) To: Jack Johnson; +Cc: Fans of the OS Plan 9 from Bell Labs On Fri, 17 Dec 2004 15:20:54 -0800, Jack Johnson <knapjack@gmail.com> wrote: > On Fri, 17 Dec 2004 10:52:51 -0800, David Leimbach <leimy2k@gmail.com> wrote: > > Mac OS X is not a microkernel architecture... but it does "have a > > microkernel" :). > > I wonder how much of this is just NeXT heritage rather than > purposefully to make the actual work of building/upgrading OS X any > easier (or any other potentially valid reason)? > I suspect they liked some of the SMP capabilities Mach was endowed with + the thread scheduling and VM. Even FreeBSD adopted the Mach VM at one point [but not the rest of Mach]. Chances are they have TONS of legacy code that requires a lot of work to get away from Mach. NeXT ran with Mach 2.5 and XNU is a modified OSF Mach 3 if I recall correctly. I don't think Mach is making anything easier for Apple except in possibly some of their real-time scheduling of threads for multimedia streaming and what-have-you. Other than that it's a pretty odd animal at times. It'd be interesting to see what would happen if they ever went with something like L4 [a more current and more successful at being a microkernel microkernel]. But L4 messaging is synchronous by specification and I think Mach has a lot of asynchronous behavior that might be hard to emulate initially. It'd be a bit of work... However NetBSD does now have some level of Darwin compatibility including a Mach layer so who knows!?!? It's pretty danged offtopic for this list though :) Dave > -Jack > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 15:34 [9fans] Acme mailreader jim 2004-12-15 15:40 ` gdiaz 2004-12-15 16:07 ` rog @ 2004-12-15 16:09 ` Russ Cox 2004-12-15 16:16 ` jim 2004-12-15 16:22 ` boyd, rounin 2 siblings, 2 replies; 69+ messages in thread From: Russ Cox @ 2004-12-15 16:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I've been trying and trying to get mailreading to work > in acme(1) on my OS X system. It works fine on a plan9 > system, e.g. mordor.tip9ug.jp, but I can't work out how to > do the same thing with acme/wily on OS X. Mail is stored > in mbox format, so it ought to be possible; maybe some > paths need amending? > > OS X seems to be fairly p9 friendly; it has open(1), > which is very similar to plumb(1), and lots of remote > services (ftp, mail etc) are mounted as filesystems, so > (despite being a "girls unix" ;-) it should be a pretty > nice host OS for plan9port. as gabi said, you need upas/fs, and i haven't ported it, mainly because pushssl() is unimplemented, and i would have been using it for pop. if you're going to edit mailboxes directly then you can avoid pushssl() but you'll have to work out the right locking code for your flavor of unix, which is not always easy. also upas/fs does its own threading and would need to be converted over to the thread library in order to run on plan9ports. the last straw was that i switched to gmail. i'm not planning to port upas/fs, but i would like to see it happen. if anyone wants to do the work and needs encouragement or direction, feel free to mail me. russ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:09 ` Russ Cox @ 2004-12-15 16:16 ` jim 2004-12-15 16:22 ` boyd, rounin 1 sibling, 0 replies; 69+ messages in thread From: jim @ 2004-12-15 16:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Russ Cox On 15 Dec 2004, at 16:09, Russ Cox wrote: > the last straw was that i switched to gmail. > Likewise; I just love seeing gmail messages in acme :-D > i'm not planning to port upas/fs, but i would like to see it > happen. if anyone wants to do the work and needs > encouragement or direction, feel free to mail me. In that case, I'll grab the source and start reading. cheers, jim ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [9fans] Acme mailreader 2004-12-15 16:09 ` Russ Cox 2004-12-15 16:16 ` jim @ 2004-12-15 16:22 ` boyd, rounin 1 sibling, 0 replies; 69+ messages in thread From: boyd, rounin @ 2004-12-15 16:22 UTC (permalink / raw) To: Russ Cox, Fans of the OS Plan 9 from Bell Labs > ... but you'll have to work > out the right locking code for your flavor of unix, which is > not always easy. this may help you out: http://www.insultant.net/tmp/mace/mail.c ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2004-12-23 16:04 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-15 15:34 [9fans] Acme mailreader jim 2004-12-15 15:40 ` gdiaz 2004-12-15 15:47 ` jim 2004-12-15 15:50 ` Joseph Stewart 2004-12-15 15:57 ` jim 2004-12-15 16:10 ` Russ Cox 2004-12-15 15:58 ` Charles Forsyth 2004-12-15 16:04 ` jim 2004-12-15 16:24 ` C H Forsyth 2004-12-15 16:31 ` jim 2004-12-15 17:07 ` Russ Cox 2004-12-15 17:30 ` jim 2004-12-15 18:33 ` Russ Cox 2004-12-15 18:49 ` jim 2004-12-15 18:36 ` Axel Belinfante 2004-12-15 18:47 ` jim 2004-12-15 18:51 ` rog 2004-12-15 18:48 ` Skip Tavakkolian 2004-12-15 16:05 ` rog 2004-12-15 16:07 ` rog 2004-12-15 16:09 ` jim 2004-12-16 0:24 ` geoff 2004-12-16 4:12 ` Ronald G. Minnich 2004-12-16 4:51 ` geoff 2004-12-16 9:25 ` jim 2004-12-16 5:13 ` Skip Tavakkolian 2004-12-16 5:17 ` geoff 2004-12-16 5:20 ` boyd, rounin 2004-12-16 5:34 ` boyd, rounin 2004-12-16 5:29 ` Skip Tavakkolian 2004-12-16 15:54 ` Ronald G. Minnich 2004-12-16 17:52 ` Skip Tavakkolian 2004-12-16 18:13 ` Dave Eckhardt 2004-12-16 5:23 ` Andy Newman 2004-12-16 15:52 ` Ronald G. Minnich 2004-12-16 8:17 ` Martin C.Atkins 2004-12-16 9:35 ` jim 2004-12-16 15:19 ` rog 2004-12-16 15:26 ` jim 2004-12-16 9:30 ` jim 2004-12-16 15:08 ` David Leimbach 2004-12-16 23:22 ` geoff 2004-12-16 23:25 ` boyd, rounin 2004-12-16 23:38 ` Ronald G. Minnich 2004-12-17 1:31 ` Skip Tavakkolian 2004-12-17 15:50 ` Ronald G. Minnich 2004-12-17 4:55 ` [9fans] Acme mailreader - now: User mode filesystems in linux Martin C.Atkins 2004-12-17 9:54 ` Martin C.Atkins 2004-12-17 10:22 ` geoff 2004-12-17 10:45 ` Martin C.Atkins 2004-12-17 11:42 ` Andy Newman 2004-12-17 15:57 ` Ronald G. Minnich 2004-12-17 12:30 ` Latchesar Ionkov 2004-12-17 15:55 ` Ronald G. Minnich 2004-12-17 13:41 ` Derek Fawcus 2004-12-17 14:42 ` Karl Magdsick 2004-12-17 14:56 ` Russ Cox 2004-12-18 0:13 ` Tim Newsham 2004-12-18 0:13 ` boyd, rounin 2004-12-18 3:49 ` Ronald G. Minnich 2004-12-23 16:04 ` boyd, rounin 2004-12-17 15:44 ` Ronald G. Minnich 2004-12-18 12:35 ` Martin C.Atkins 2004-12-17 18:52 ` [9fans] Acme mailreader David Leimbach 2004-12-17 23:20 ` Jack Johnson 2004-12-18 1:00 ` David Leimbach 2004-12-15 16:09 ` Russ Cox 2004-12-15 16:16 ` jim 2004-12-15 16:22 ` boyd, rounin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).