Re: [9fans] acme mail on unix
> Maildir uses the structure folder/{tmp,cur,new}/unique.file.name.
> The files are required to be uniquely named, and there is a convention for
> the intermediate directories. djb has a brief but detailed specification
> under cr.yp.to somewhere, if you want to google for it.
http://cr.yp.to/proto/maildir.html
Re: [9fans] acme mail on unix
| MH uses monotonically-increasing small positive integers to number
| messages within a folder. Maildir, as I recall, uses large
| pseudo-random numbers, or what appear to be pseudo-random numbers.
Maildir uses the structure folder/{tmp,cur,new}/unique.file.name.
The files are required to be uniquely named, and there is a convention for
the intermediate directories. djb has a brief but detailed specification
under cr.yp.to somewhere, if you want to google for it.
Re: [9fans] acme mail on unix
MH uses monotonically-increasing small positive integers to number messages within a folder. Maildir, as I recall, uses large pseudo-random numbers, or what appear to be pseudo-random numbers. --- Begin Message --- > On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > > Eventually I might replace the mh programs with code from > > Plan 9 (still leaving the mh disk layout) but I don't expect to > > do that any time soon. > > Personally, I'd rather that wasn't the case. I'd rather see a version of > the MH utilities (or a subset of the useful ones) that know how to deal with > Maildir or IMAP (given the discrete nature of the MH commands, the latter > might be hard and/or slow). What is the difference between mh's layout and maildir? I thought they were the same. Russ--- End Message ---
[9fans] Re: patch/list killbig-nits
> > I'm not happy with the proliferation of magic process names. > > Instead, why not check if(p->procmode&0222). The startup script > > can then chmod -w /proc/importantguys/ctl. > Good idea, but that would allow a (malicious) user to protect it's own hogs, > maybe we should also check that it's not owned by eve? ugly too, but I can't > think of anything better. There are so many other things a malicious user could do instead. Russ
[9fans] Re: patch/list killbig-nits
> d-rwxrwxr-x M 815285 uriel sys 0 Jan 19 00:58 killbig-nits > from [EMAIL PROTECTED] > /sys/src/9/port/proc.c > /sys/src/9/port/swap.c > Don't kill fossil or venti even if they are hogs! > > Move a comment about "no swap configured" to swap.c because it's > not always correct(killbig() is called by ^T^Tk). > > > Thu Jan 19 11:35:35 EST 2006 rsc > The extra print in swap.c is unnecessary, since it will print > "no physical memory" right after calling killbig. I edited things in a way that avoided removing any existing info while fixing the incorrect cases, I'm happy with any messages and wording you like as long as they are correct :) > I'm not happy with the proliferation of magic process names. > Instead, why not check if(p->procmode&0222). The startup script > can then chmod -w /proc/importantguys/ctl. Good idea, but that would allow a (malicious) user to protect it's own hogs, maybe we should also check that it's not owned by eve? ugly too, but I can't think of anything better. uriel
Re: [9fans] Ok last one..
even if permission checking is disabled, it will not work, because vgactl does not exist in /dev, because '#v' has not been bound there, so your >/dev/vgactl is attempting to create it, which fails (because `mounted directory forbids creation', which means it was mounted or bound without -c or MCREATE), which probably means you need bind -a '#v' /dev first, or you can use >'#v/vgactl' --- Begin Message --- On stand alone cpu-auth server, is there a way to around the following error message? /dev/vgactl: rc: can't open: mounted directory forbids creation as a result of command echo hwaccel off > /dev/vgactl when permission checking is disabled. -ishwar--- End Message ---
Re: [9fans] Maybe it is april fool's after all ...
i like it when chip companies ask "why would you want to do that" and the obvious answer is "because the data sheet says i can and i want to". i've been thru this with a few vendors. brucee On 1/20/06, Charles Forsyth <[EMAIL PROTECTED]> wrote: > >>when is a .so not a .so? when it's a ld script of course! > >>yup, /lib/libc.so on my fc4 box is a . script. > > curiously, i was just installing fc4 on a machine today. > following an i/o error on a few blocks of a hard drive containing an ext3, > that had emptied /usr/etc to the confusion of all, subsequent use of > redhat-something's fsck destroyed the whole file system rather instantly, > so i thought it might be time for an upgrade. > fc4's installation said there was an i/o error on installation, > that was ``a serious problem'', it could not continue, OK? > as usual my ``that's not OK, actually'' met with a blank face, > and OK rebooted the system. i think it's all a hint to replace the drive. > clearly, from ron's message, i'm in for a good time! > we'll know computing has cracked it when that sort of thing > is a question on ``who wants to be a millionaire?''. > all helps to keep those synapses active. > >
Re: [9fans] GNU binutils: you can't make this stuff up
what does unicode have to do with compiler design? does "microkernel" mean anything specific? i'm not convinced that it does. - erik Brantley Coile <[EMAIL PROTECTED]> writes | | Microkernels are to OS design what Unicode was to compiler design.
[9fans] Ok last one..
On stand alone cpu-auth server, is there a way to around the following error message? /dev/vgactl: rc: can't open: mounted directory forbids creation as a result of command echo hwaccel off > /dev/vgactl when permission checking is disabled. -ishwar
Re: [9fans] acme mail on unix
> On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > > Eventually I might replace the mh programs with code from > > Plan 9 (still leaving the mh disk layout) but I don't expect to > > do that any time soon. > > Personally, I'd rather that wasn't the case. I'd rather see a version of > the MH utilities (or a subset of the useful ones) that know how to deal with > Maildir or IMAP (given the discrete nature of the MH commands, the latter > might be hard and/or slow). What is the difference between mh's layout and maildir? I thought they were the same. Russ
Re: [9fans] acme mail on unix
On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > Eventually I might replace the mh programs with code from > Plan 9 (still leaving the mh disk layout) but I don't expect to > do that any time soon. Personally, I'd rather that wasn't the case. I'd rather see a version of the MH utilities (or a subset of the useful ones) that know how to deal with Maildir or IMAP (given the discrete nature of the MH commands, the latter might be hard and/or slow). - Dan C.
Re: [9fans] Maybe it is april fool's after all ...
>>when is a .so not a .so? when it's a ld script of course! >>yup, /lib/libc.so on my fc4 box is a . script. curiously, i was just installing fc4 on a machine today. following an i/o error on a few blocks of a hard drive containing an ext3, that had emptied /usr/etc to the confusion of all, subsequent use of redhat-something's fsck destroyed the whole file system rather instantly, so i thought it might be time for an upgrade. fc4's installation said there was an i/o error on installation, that was ``a serious problem'', it could not continue, OK? as usual my ``that's not OK, actually'' met with a blank face, and OK rebooted the system. i think it's all a hint to replace the drive. clearly, from ron's message, i'm in for a good time! we'll know computing has cracked it when that sort of thing is a question on ``who wants to be a millionaire?''. all helps to keep those synapses active.
[9fans] disk error info
Ok, After recovering from my seccond disk failure in a month - both part of the same batch so I suspose it makes sense. I began to wonder, anyone any ideas about how to probe a scsi disk for the number entries in its spare table? I would like to get a bit or warning of impending failure (if I can) next time. -Steve
[9fans] plan9.ini question
Is there way to specify in plan9.ini to switch off the video hwaccel that is achieved produced by % echo hwaccel off > /dev/vgactl -ishwar
[9fans] textonly install question
I installed Plan 9 under vmware-5.5 using inst/textonly The system stays stuck at int: starting /bin/rc on first boot/reboot How do I get the prompt? -ishwar
[9fans] Maybe it is april fool's after all ...
when is a .so not a .so? when it's a ld script of course! yup, /lib/libc.so on my fc4 box is a . script. which is why l4 would not build ... /bin/ld from olden times does not understand the GROUP command below. [EMAIL PROTECTED] ~]$ file /usr/lib/libc.so /usr/lib/libc.so: ASCII C program text [EMAIL PROTECTED] ~]$ cat !$ cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) [EMAIL PROTECTED] ~]$ ron
Re: [9fans] GNU binutils: you can't make this stuff up
c'mon microcode is fun. guido is full of it - all concurrent. the easiest example is string equality (rather popular really). doodling in the sand on the beach helps with microcode design. brucee On 1/20/06, Brantley Coile <[EMAIL PROTECTED]> wrote: > Microkernels are to OS design what Unicode was to compiler design.
Re: [9fans] 5a and optimization
the mips compilers (at least 0c and ec etc.) support psuedo instrs (NOSCHED, SCHED i think) which really stops your low level code being screwed with. brucee On 1/20/06, Noah Evans <[EMAIL PROTECTED]> wrote: > Yeah, I put it in l.s(probably should put it in rom.s but who knows). > The linker eats the text if I leave the branch in. So I put the > branch in a WORD and(thanks to Charles' advice) use -E to go to the > initial TEXT _rom section. > > Very true about the rom weirdness. > > Thank you very much for the advice. I really appreciate the support. > > Noah > > On Jan 20, 2006, at 12:49 AM, [EMAIL PROTECTED] wrote: > > > One way is to make it TEXT, e.g. the multiboot header and GDT stuff > > in /sys/src/9/pc/l.s. > > > > Agreed, the loaders don't make such things easy to do, but writing > > assembler and making odd format binaries is the exception, not the > > rule. > > > > --jim > > > > On Thu Jan 19 06:31:30 EST 2006, [EMAIL PROTECTED] wrote: > >> How do you keep the linker from optimizing away your rom headers and > >> other data? I had to put a noop in front of my first text section to > >> keep the linker from putting the main loop in front of it. I also had > >> to code the branch past the rom header in hex to keep the linker from > >> eating the header(it's unreachable). > >> > >> Best, > >> > >> Noah > >
Re: [9fans] acme mail on unix
> Hey Russ, > I'd love to try out your script - problem is nmh doesn't seem to like > modern-ish utilities (gcc 4 et al). Would you know of any other > utility which would have the same functionality? I would suggest trying to find an earlier gcc or prebuilt binaries. Eventually I might replace the mh programs with code from Plan 9 (still leaving the mh disk layout) but I don't expect to do that any time soon. Russ
Re: [9fans] GNU binutils: you can't make this stuff up
Microkernels are to OS design what Unicode was to compiler design.
Re: [9fans] acme mail on unix
Hey Russ, I'd love to try out your script - problem is nmh doesn't seem to like modern-ish utilities (gcc 4 et al). Would you know of any other utility which would have the same functionality?
Re: [9fans] GNU binutils: you can't make this shit up
On 1/19/06, Eirik Johnson <[EMAIL PROTECTED]> wrote: There is something to be said for microkernelsthey allow for a lot less headaches with kerneldevelopment, and it could drastically improve plan 9'sportability, a key feature.Disagree, to some extent. Microkernels tie you down to a particular set of abstractions for writing OS code. I think a lot of time is spent trying to figure out how to morph the primitives that are exposed by the microkernel API into what you're trying to express in your kernel. EROS, for example, multiplexed a single system call to create all the OS primitives for the system.L4 really only has 7 system calls, but also has several APIs available that combine things in different, and hopefully not pessimistic ways to make things easier. It's a layer of abstractions on another layer of abstractions. Also, the multi-server approach taken by the GNU/Hurdis innovative and well suited to SMP and distributed environments. However, the FSF has a role and the GNUproject is (and should be) a side project for them.The real problem with it, though, is that C (like plan9) was designed with portability as a major feature, and the GNU extensions in GCC aren't helpingportability. It's kinda like microsoft's C#, they maybe wonderful features, but you missed the whole point.True, and this may have caused very serious problems with development. For a long time, possibly even still today you were limited to 2GB partitions. Also there was no pppd driver. I have a hunch that their multi-server design stuck them into a place where these things became hard to do correctly. I have seen 2 different patches floating around for Hurd to add >2GB partitions as well as pppd [borrowed from FreeBSD in fact] but neither seemed to make it into into the main source tree because, it just wasn't quite correct. At some point, HURD developers became so frustrated with Mach, they switched to L4. I followed a lot of this development as a lurker... and I'd have to say that it doesn't look good again for progress and people inside FSF are questioning the design *again*. Now those examples aside, I know for a fact you can write useful OSes with a microkernel. I've seen and used a few of them. Someone even took the Io programming language and ported it to L4 to make what appears to be something on the lines of a ROM BASIC for an OS :). This might be really good in certain embedded applications, who knows. Also the HoP/House project, which takes the GHC Haskell runtime and turns it into an OS via a special Monad for hardware abstractions, looks like it may also get ported to L4.There's no magic wand for OS development. --- alexandr babic <[EMAIL PROTECTED]> wrote: > i think 9fans should write plan9 native programs not> trying other waste> to import.>> alexandr.>>> Bruce Ellis pí¹e v Èt 19. 01. 2006 v 00:45 +1100:> > anyone who is serious trying anything starting > with "g" with> > kenc (apart from "grep") is barking up the wrong> > mountain ave.> >> > brucee> __ Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection aroundhttp://mail.yahoo.com
Re: [9fans] 5a and optimization
Yeah, I put it in l.s(probably should put it in rom.s but who knows). The linker eats the text if I leave the branch in. So I put the branch in a WORD and(thanks to Charles' advice) use -E to go to the initial TEXT _rom section. Very true about the rom weirdness. Thank you very much for the advice. I really appreciate the support. Noah On Jan 20, 2006, at 12:49 AM, [EMAIL PROTECTED] wrote: One way is to make it TEXT, e.g. the multiboot header and GDT stuff in /sys/src/9/pc/l.s. Agreed, the loaders don't make such things easy to do, but writing assembler and making odd format binaries is the exception, not the rule. --jim On Thu Jan 19 06:31:30 EST 2006, [EMAIL PROTECTED] wrote: How do you keep the linker from optimizing away your rom headers and other data? I had to put a noop in front of my first text section to keep the linker from putting the main loop in front of it. I also had to code the branch past the rom header in hex to keep the linker from eating the header(it's unreachable). Best, Noah
Re: [9fans] 5a and optimization
One way is to make it TEXT, e.g. the multiboot header and GDT stuff in /sys/src/9/pc/l.s. Agreed, the loaders don't make such things easy to do, but writing assembler and making odd format binaries is the exception, not the rule. --jim On Thu Jan 19 06:31:30 EST 2006, [EMAIL PROTECTED] wrote: > How do you keep the linker from optimizing away your rom headers and > other data? I had to put a noop in front of my first text section to > keep the linker from putting the main loop in front of it. I also had > to code the branch past the rom header in hex to keep the linker from > eating the header(it's unreachable). > > Best, > > Noah
Re: [9fans] GNU binutils: you can't make this shit up
Eirik Johnson wrote: There is something to be said for microkernels they allow for a lot less headaches with kernel development, and it could drastically improve plan 9's portability, a key feature. it's not april fool's ron
[9fans] 5a and optimization
How do you keep the linker from optimizing away your rom headers and other data? I had to put a noop in front of my first text section to keep the linker from putting the main loop in front of it. I also had to code the branch past the rom header in hex to keep the linker from eating the header(it's unreachable). Best, Noah
Re: [9fans] GNU binutils: you can't make this shit up
there is nothing innovative about hurd, not even the fact that it doesn't work and has taken years to get so unstable. brucee On 1/19/06, erik quanstrom <[EMAIL PROTECTED]> wrote: > > Eirik Johnson <[EMAIL PROTECTED]> writes > > | > | There is something to be said for microkernels > | they allow for a lot less headaches with kernel > | development, and it could drastically improve plan 9's > | portability, a key feature. > > "microkernels" cover a broad range. mach is > bigger than the plan 9 kernel. bigger than the linux kernel, even. > and linux is 90% device drivers. > > i hold out some hope for l4. > > | Also, the multi-server approach taken by the GNU/Hurd > | is innovative and well suited to SMP and distributed > | environments. > > what's innovative about the hurd? unless i'm missing something > plan9 fileservers are isomorphic with hurd daemons, conceptually. > the major difference being, in the hurd a server exports a random > interface, in plan9 a server exports a filesystem. > hurd isn't even an os. it needs a microkernel. > > However, the FSF has a role and the GNU > | project is (and should be) a side project for them. > | The real problem with it, though, is that C (like plan > | 9) was designed with portability as a major feature, > | and the GNU extensions in GCC aren't helping > | portability. It's kinda like microsoft's C#, they may > | be wonderful features, but you missed the whole point. >
Re: [9fans] GNU binutils: you can't make this shit up
Eirik Johnson <[EMAIL PROTECTED]> writes | | There is something to be said for microkernels | they allow for a lot less headaches with kernel | development, and it could drastically improve plan 9's | portability, a key feature. "microkernels" cover a broad range. mach is bigger than the plan 9 kernel. bigger than the linux kernel, even. and linux is 90% device drivers. i hold out some hope for l4. | Also, the multi-server approach taken by the GNU/Hurd | is innovative and well suited to SMP and distributed | environments. what's innovative about the hurd? unless i'm missing something plan9 fileservers are isomorphic with hurd daemons, conceptually. the major difference being, in the hurd a server exports a random interface, in plan9 a server exports a filesystem. hurd isn't even an os. it needs a microkernel. However, the FSF has a role and the GNU | project is (and should be) a side project for them. | The real problem with it, though, is that C (like plan | 9) was designed with portability as a major feature, | and the GNU extensions in GCC aren't helping | portability. It's kinda like microsoft's C#, they may | be wonderful features, but you missed the whole point.
Re: [9fans] GNU binutils: you can't make this shit up
can i put this in m book? --- forsyth the way to get good portability is to have clear, well-designed interfaces that abstract away from hardware peculiarities, and map those to the hardware (rather than, say, reflecting in the interfaces the union of every peculiarity of all hardware known to you at the time). some of the hard bits about kernel development are: - getting accurate documentation for the processor, devices, existing bootstrap, etc. - getting anything loaded into the wretched machine at all - deciding how your kernel should look, what it should do, how it should change - working out a good infrastructure for networks, devices coming and going, power, etc. - finding time and/or money to do any of it
Re: [9fans] GNU binutils: you can't make this shit up
> There is something to be said for microkernels > they allow for a lot less headaches with kernel > development, and it could drastically improve plan 9's > portability, a key feature. term% pwd /usr/forsyth/src/xen3/xen-unstable/xen/arch/x86 term% wc -l mm.c shadow32.c shadow_guest32.c 3519 mm.c 3397 shadow32.c 18 shadow_guest32.c 6934 total # and that could be the tip of an iceberg, since that's x86-only # now let's look at several non-micro/hyper kernels term% cd /sys/src/9/pc term% wc -l mmu.c 1043 mmu.c term% cd /usr/inferno/os/pc term% wc -l mmu.c 321 mmu.c now if you're using the first implementation above, you still also need something like the second or third as well (but a little different). that's a hypervisor (but one that is claimed in a paper to be `microkernels done right'). its code is much bigger because it actually does much more than 9's or Inferno's. i'm sure last time i looked (which to be fair was years ago) mach had quite a bit of complex mmu code too. which is likely to give you more headaches, and how strong? perhaps we should have an ibuprofen rating for kernels? portability? i have done kernels (including small micro-ish ones) myself, and i have worked with other systems extensively over the years. in my experience, some of the interfaces the micro/hypers present is HARDER to drive than the underlying hardware, possibly more frustrating, not as well documented, and changes. and of course there's more code in the end. somtimes much more. it wouldn't be so bad if people hadn't forgotten an important lesson from THE: the idea is for each layer to provide increasingly higher levels of abstraction, the better to reason about. of course, in several cases, the newer systems are the way they are to make porting Linux easier (well, that's my impression), presumably on the grounds that its interfaces are all over the place, x86-oriented, and hard to change. then there are the interfaces for device drivers... not that i'm bitter. the way to get good portability is to have clear, well-designed interfaces that abstract away from hardware peculiarities, and map those to the hardware (rather than, say, reflecting in the interfaces the union of every peculiarity of all hardware known to you at the time). some of the hard bits about kernel development are: - getting accurate documentation for the processor, devices, existing bootstrap, etc. - getting anything loaded into the wretched machine at all - deciding how your kernel should look, what it should do, how it should change - working out a good infrastructure for networks, devices coming and going, power, etc. - finding time and/or money to do any of it now, while it can be really tedious when you get yourself into the state where the hardware resets without notice (and worse, takes quite some time to get to that state, or requires ... something ... but what is it???), it often isn't something that would be fixed by a micro-kernel, but rather by better hardware, documentation, more careful coding, fewer interruptions, more time to think, more energy, and of course more intelligence. lacking any or all of these, it's still usually easier to debug a component of a smaller system with a straightforward model overall. that might be true of some micro-kernels, but not all, and it isn't limited to them; a more `conventional' kernel can be quite acceptably modular.
Re: [9fans] GNU binutils: you can't make this shit up
There is something to be said for microkernels they allow for a lot less headaches with kernel development, and it could drastically improve plan 9's portability, a key feature. Also, the multi-server approach taken by the GNU/Hurd is innovative and well suited to SMP and distributed environments. However, the FSF has a role and the GNU project is (and should be) a side project for them. The real problem with it, though, is that C (like plan 9) was designed with portability as a major feature, and the GNU extensions in GCC aren't helping portability. It's kinda like microsoft's C#, they may be wonderful features, but you missed the whole point. --- alexandr babic <[EMAIL PROTECTED]> wrote: > i think 9fans should write plan9 native programs not > trying other waste > to import. > > alexandr. > > > Bruce Ellis pí¹e v Èt 19. 01. 2006 v 00:45 +1100: > > anyone who is serious trying anything starting > with "g" with > > kenc (apart from "grep") is barking up the wrong > > mountain ave. > > > > brucee > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
