[9fans] What happened on lib9p?

[9fans] What happened on lib9p?

[kokamoto]

I'm still seeing 'sources' and 9front sources.
In 9fron sources there are significant changes on lib9p
and those time stamp is younger than 2011.

Something important happened on 9P protocol
while I was peacefully sleeping?

Kenji

Re: [9fans] What happened on lib9p?

[erik quanstrom]

On Sun Apr 20 05:47:44 EDT 2014, kokamoto@hera.eonet.ne.jp wrote:
> I'm still seeing 'sources' and 9front sources.
> In 9fron sources there are significant changes on lib9p
> and those time stamp is younger than 2011.
>
> Something important happened on 9P protocol
> while I was peacefully sleeping?

all i see is rearrangement, and support for shr.

- erik

Re: [9fans] What happened on lib9p?

[cinap_lenrek]

9front adds a inferno inspired mechanism for handling
requests in parallel to the 9p service loop called
srvrelease()/srvacquire().

often explicitely breaking up your request handling into
separate processes and handing off a request to a process
seems overkill. instead, you can do a srvrelease() which will
(if neccesary) spawn a new process to handle the 9p service
loop while your calling process is now free to block.
once you finished you do a srvacquire() to serialize with
the 9p service loop again.

i used this to make usb drivers multithreaded. usb devs can
be slow to respond or sometimes even hang. as the filesystem is
bound onto /dev, a hanging usb device would hang all walks
on /dev making the system unusable with a single threaded
implementation. srvrelease()/srvacquire() made these changes
trivial todo.

--
cinap

Re: [9fans] What happened on lib9p?

[erik quanstrom]

> i used this to make usb drivers multithreaded. usb devs can
> be slow to respond or sometimes even hang. as the filesystem is
> bound onto /dev, a hanging usb device would hang all walks
> on /dev making the system unusable with a single threaded
> implementation. srvrelease()/srvacquire() made these changes
> trivial todo.

cool!

- erik

Re: [9fans] What happened on lib9p?

[kokamoto]

Thanks cinap

> i used this to make usb drivers multithreaded.

Wow!

I found also many eqlock() call instead of qlock().
Is this also related to usb slowness?

Kenji

Re: [9fans] What happened on lib9p?

[cinap_lenrek]

no, it is not. in the kernel, you can only have
one process doing a sleep on a rendezvous point
at a time.

so when you have multiple waiter processes, you
put a qlock arround the sleep so the first process
goes into the sleep and follow up processes
will get queued on the qlock.

the problem with this construct is that only
the first process thats in the sleep can be
interrupted / killed. the processes queued
in the qlock are uninterruptable / unkillable
as long as they wait for the qlock to be
available.

the eqlock() is a interruptable version of
the qlock() call. that is, it can error out
when the process receives a note.

--
cinap

Re: [9fans] What happened on lib9p?

[kokamoto]

> the eqlock() is a interruptable version of
> the qlock() call. that is, it can error out
> when the process receives a note.

Thans cinap!

I'm checking how I can incorporate your nusb codes
into my 'sources' conservative version usb codes.
Of course, it's should be my personal hiden version.☺

By the way, once upon a time ago, I tried early version
of 9front to bootup from diskless terminal and failed.
It's no problem now?

Kenji

Re: [9fans] What happened on lib9p?

[Aram Hăvărneanu]

On Tue, Apr 22, 2014 at 3:46 AM,  <kokamoto@hera.eonet.ne.jp> wrote:
> I tried early version
> of 9front to bootup from diskless terminal and failed.
> It's no problem now?

I'm not sure what you mean. I have only one 9front machine with a
disk, all other are diskless and work fine. I don't remember this ever
being a problem.

-- 
Aram Hăvărneanu

Re: [9fans] What happened on lib9p?

[kokamoto]

> I'm not sure what you mean. I have only one 9front machine with a
> disk, all other are diskless and work fine.

Do you network boot those diskless machine?
When I tried I could use drawterm, but network boot didn't.

Kenji

Re: [9fans] What happened on lib9p?

[Aram Hăvărneanu]

I PXE-boot most of them, yes.

-- 
Aram Hăvărneanu

Re: [9fans] What happened on lib9p?

[kokamoto]

> I'm checking how I can incorporate your nusb codes
> into my 'sources' conservative version usb codes.
> Of course, it's should be my personal hiden version.☺

I found it unneccessary.

The 'sources' usb/disk recognizes partitions already.
However, after I applied 9front's kernel codes (not include eqlock()),
the file copy speed got about 10 times quicker.
Yeah, this is an acceptable speed to use usb disk here.
Thanks every one.

Now, I can proceed myself more...

PS.   I played around with Windows go, and got
much frustrated.☺

Re: [9fans] What happened on lib9p?

[Skip Tavakkolian]

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

that means windows is working as expected :)


On Sun, May 4, 2014 at 10:34 PM, <kokamoto@hera.eonet.ne.jp> wrote:

>
> PS.   I played around with Windows go, and got
> much frustrated.☺
>
>
>

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