From mboxrd@z Thu Jan 1 00:00:00 1970 From: giacomo@tesio.it (Giacomo Tesio) Date: Fri, 6 Jan 2017 20:42:32 +0100 Subject: [9fans] A heartfelt thanks... :-) In-Reply-To: <20170106093414.GA26942@alice> References: <20170106093414.GA26942@alice> Message-ID: Topicbox-Message-UUID: b15b7640-ead9-11e9-9d60-3106f5b1d025 2017-01-06 10:34 GMT+01:00 Anthony Martin : > Ciao Giacomo, > Ciao Anthony, ottime domande! :-) Let's start from the easy ones: > Oh, and where are the man pages? /doc/hacking is missing. Man pages in Jehanne will be readable in source form. Cat should be enough to render them. This means that I have to port them from troff to something like markdown or commonmark (or something even better if possible). Whatever will be the format, it must be readable in source form. /doc/hacking/ is just waiting to be filled. I know it's important, but so far I gave priority to hacking itself, instead of documentation. The state of the web site is a sad effect of this choice. I will try to scratch something in the next week. > I'm interested in reading about your awake system call and the changes > you've made to rendezvous and the variuos locks in libc. > Well awake is the complement of sleep: instead of blocking for a number of ms, it wakes up a process blocked on a syscall after a number of ms. Actually right now the only syscall that can be awaken is rendezvous, but I will add support for it to all others blocking syscalls. As for it's impact on libc I will write something asap. Why did you choose to create devself? Everything it does seems > better suited to devproc. If I was going that route, I'd instead > create a QTDIR file in devproc called #p/self that is just another > view into #p/$pid. Then brk and chdir would be control messages > written to #p/self/ctl. Same with seg^(attach detach free). You > could also make those be control messages written to #p/self/segment > instead. > I evaluated that option and actually devself and devproc are related, but different: - in Jehanne you cannot access #p after an rfork(RFNOMNT), but you can still access #0/segment - in Jehanne you cannot access #c after an rfork(RFNOMNT), but you can access #0/null or #0/pid - wdir is present in both #p and #0 so that chdir first try to open /proc/$pid/wdir and only on failure try with #0/wdir. This allows a process to intercept changes to the working directory of another (that want to cooperate). Guess what's the first use case for this (still to be implemented, actually)? Note that both devices are still work in progress! For example this state of things poses some security concern, but it's part of an overall design that will include a new flag to rfork to limit the process visible in #p to children and other security related changes to its working. > > Also, I think it's a mistake to overload the return value of the > remove system call for passing arbitrary integers out of the kernel. > I understand why you want something like that, however. Moving > system calls into reads and writes of various files increases the > number of context switches since you have to open and close the > files. Why not do exactly what you want and make a new system > called readint or something? > No, well... actually it's not a just matter of performance. Remove is not the only "overloaded" system call in Jehanne, it's just the easy to catch! :-D Again this is a rather large topic strictly linked to the file protocol that I'm designing. Devices and file servers will allowed to assign custom semantics to values that are not used by the operating system. For remove and close this just means all the possible return values except ~0 that is used for errors. For open, pread and pwrite it means all negative values of long arguments and return values (again except ~0). Giacomo -------------- next part -------------- An HTML attachment was scrubbed... URL: