>So, essentially everyone came back to what I said originally. >"Keep posix out of the kernel and make it a library instead." Not everyone. Some people. PERSONALLY, the way that I see it. the difference between a kernel-addon and incorporating into the kernel is only slightly more than a BUILD ISSUE. That sort of a decision should not stop us from coding. >I drew *a-lot* of flak for that. Especially from linux/eunucs people. Redirect all flak to me. :-) Makes your life easier. Design decisions flak should always go to team leaders. If we talk about the design, which I seem to remember that we did, and others don't like it, tell them to come and see me. :-) >Oh, well.....sticks and stones I guess.... >I've been designing it as a library anyway, SO THERE! NYA! =} Hey - if it works, no one will have anything to say. >Told ya so! Told ya so!....... >I just want the kernel and file system specs so I can get things >underway. Normally I would say this offlist, but I think that everyone needs to hear it: Pretend that you are writing for R5. Pretend that you are discontent with R5 posix for some reason, and want/need to replace it. How would you do that? Probably with a kernel-add-on. Since posix == C, not C++, you would need to do something icky, like make all of your functions start with a prefix: OBOS_fork or something. Something we can quick and easily search and replace. Write some test code. Write some code. Test it critically. Make sure it works. If, in the end, we want to compile it into the kernel, we take out the load/unload functions, add syscalls or whatever interface we decide on, and ship it. >Someone wake me up when it's my turn to work, will ya. <shaking Peter violently> Now is the time! :-) Michael >Peter > >PS. (to purists) Yeah, it's a windows email message. Your point is....? Whatever works for you.