Re: [9fans] A heartfelt thanks... :-)
On Fri, Nov 16, 2018, at 11:35 PM, Giacomo Tesio wrote: > Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener > ha scritto: > > Please forgive my laziness in not reading the code, but how do you actually > > implement sleep? Does the process read a file guaranteed to block forever, > > or what? > > No problem. Actually sleep is very short: > https://github.com/JehanneOS/jehanne/blob/master/sys/src/lib/c/9sys/sleep.c#L23 > > The blocking system call used in sleep is rendezvous that, in Jehanne, > can never occur at tag ((void*)~0). A rendevous with nothing! That's neat. Does C require casts for void pointer? The casts in the rendevous line make it hard to read.
Re: [9fans] A heartfelt thanks... :-)
Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener ha scritto: > Please forgive my laziness in not reading the code, but how do you actually > implement sleep? Does the process read a file guaranteed to block forever, > or what? No problem. Actually sleep is very short: https://github.com/JehanneOS/jehanne/blob/master/sys/src/lib/c/9sys/sleep.c#L23 The blocking system call used in sleep is rendezvous that, in Jehanne, can never occur at tag ((void*)~0). Giacomo
Re: [9fans] A heartfelt thanks... :-)
On Fri, Nov 16, 2018, at 2:03 AM, Giacomo Tesio wrote: > Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin > ha scritto: > > I'm interested in reading about your awake system call and the changes > > you've made to rendezvous and the variuos locks in libc. > > Hi Anthony, sorry for the 2 years delay, but I've finally wrote about awake. > http://jehanne.io/2018/11/15/simplicity-awakes.html > > Feel free to ask any question! I like this single interface to timeouts. I'm very much in favour of things like this rather than jamming features into interfaces. Please forgive my laziness in not reading the code, but how do you actually implement sleep? Does the process read a file guaranteed to block forever, or what?
Re: [9fans] A heartfelt thanks... :-)
Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin ha scritto: > I'm interested in reading about your awake system call and the changes > you've made to rendezvous and the variuos locks in libc. Hi Anthony, sorry for the 2 years delay, but I've finally wrote about awake. http://jehanne.io/2018/11/15/simplicity-awakes.html Feel free to ask any question! Giacomo
Re: [9fans] A heartfelt thanks... :-)
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
Re: [9fans] A heartfelt thanks... :-)
Ciao Giacomo, 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. 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? Oh, and where are the man pages? /doc/hacking is missing. I'm interested in reading about your awake system call and the changes you've made to rendezvous and the variuos locks in libc. Cheers, Anthony
