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

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

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Hi, I've just published a summary of my last year of experiments with
Jehanne  with a thanks to these communities and to their members:

  http://jehanne.io/2017/01/06/a-year-with-jehanne.html

It's worthless to say that I couldn't have done anything without your code
and your help.


Thanks.


Giacomo

[-- Attachment #2: Type: text/html, Size: 486 bytes --]

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

[Anthony Martin]

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

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

[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>

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

[Giacomo Tesio]

Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin
<ality@pbrane.org> 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... :-)

[Ethan Gardener]

On Fri, Nov 16, 2018, at 2:03 AM, Giacomo Tesio wrote:
> Il giorno ven 6 gen 2017 alle ore 10:38 Anthony Martin
> <ality@pbrane.org> 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... :-)

[Giacomo Tesio]

Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener
<eekee57@fastmail.fm> 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... :-)

[Ethan Gardener]

On Fri, Nov 16, 2018, at 11:35 PM, Giacomo Tesio wrote:
> Il giorno ven 16 nov 2018 alle ore 22:39 Ethan Gardener
> <eekee57@fastmail.fm> 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.