[9fans] A heartfelt thanks... :-)

[giacomo@tesio.it (Giacomo Tesio)]

2017-01-06 10:34 GMT+01:00 Anthony Martin <ality at pbrane.org>:

> 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: <http://mail.9fans.net/private/9fans/attachments/20170106/7ed94ee9/attachment.html>