[9fans] these are release of 9front?

[9fans] these are release of 9front?

[Francesco Cardi]

http://ninetimes.cat-v.org/news/

in these releases 9front there are customizations to the system or
just added firmware and patches?

--
Cardi Francesco alias Il Parente
Free Software activist
CEO/President Movimento Culturale GNU CODICE LIBERO

Diaspora*: https://joindiaspora.com/u/ilparente
Identi.ca: https://identi.ca/cardifrancesco
Jabber: ilparente@jabber.org

Re: [9fans] these are release of 9front?

[John Floren]

I recommend checking out the 9front list,
https://groups.google.com/forum/?fromgroups#!forum/9front. They
announce the new releases there and list the changes. It would also be
a good place for asking about 9front.

john

On Mon, Jan 7, 2013 at 5:07 PM, Francesco Cardi
<cardifrancesco@gmail.com> wrote:
> http://ninetimes.cat-v.org/news/
>
> in these releases 9front there are customizations to the system or
> just added firmware and patches?
>
> --
> Cardi Francesco alias Il Parente
> Free Software activist
> CEO/President Movimento Culturale GNU CODICE LIBERO
>
> Diaspora*: https://joindiaspora.com/u/ilparente
> Identi.ca: https://identi.ca/cardifrancesco
> Jabber: ilparente@jabber.org
>

Re: [9fans] these are release of 9front?

[sl]

> http://ninetimes.cat-v.org/news/
>
> in these releases 9front there are customizations to the system or
> just added firmware and patches?

It's a fork.

-sl

Re: [9fans] these are release of 9front?

[Richard Miller]

> in these releases 9front there are customizations to the system or
> just added firmware and patches?

Some things added, some things removed (e.g. fossil file system),
some things replaced with new versions which aren't able to
interoperate with Plan 9 programs (e.g. usb subsystem).

Re: [9fans] these are release of 9front?

[cinap_lenrek]

how can it not interoperate with plan9 programs? the usb subsystem
in 9front just organizes the instantiation of userspace drivers
differently. the kernel hci drivers and interfaces are the same
(biggest difference is that we added buffer delay control for iso
endpoints for usb audio).

instead of embedding all usb drivers in usbd, we run them as
separate fileservers/programs using lib9p instead of a
usb-fileserver-driver-framework-factory.

to get these fileservers into a global namespace, we created a
device that lets one register global mount points. so when i plug
in my usb camera, nusb/ptp gets started and the cameras filesystem
appears under /shr/sdU1.2 ect. a lot of complexity can be removed
from the drivers when one has its own processes and not have to
worry about sharing memory and filedescriptors with everything
else. a crash in one driver doesnt bring all usb down and one
can just kill a driver and attach another one for debugging without
loosing the other devices or the hub.

in a way, this is just like the old usb stack worked. you just
have a small usb helper lib for common stuff like activating
endpoints and parsing descriptors and distinct programs for
drivers. to make it work for hotplug, you use the /shr instead
of /srv.

all this doesnt matter for programs using usb devices. the
filesystem interfaces behave the same.

--
cinap

Re: [9fans] these are release of 9front?

[Richard Miller]

> how can it not interoperate with plan9 programs? the usb subsystem
> in 9front just organizes the instantiation of userspace drivers
> differently. ...

That's what I was referring to.  Plan 9 usb device drivers are
user space programs, which use the usb subsystem (including usbd)
as part of their operation.  If I write a driver to work with
Plan 9 usbd, will it work with 9front usbd?  If I write a driver
to work with 9front usbd, will it work with Plan 9 usbd?

Re: [9fans] these are release of 9front?

[cinap_lenrek]

ah, ok. yes, the drivers would be different. but its not hard
to port. its mostly removing all the refcounting and and plan9 usb
framework activation and just wrap it in a normal plan9 filesystem.

many drivers needed a rewrite anyway (like usb audio) because they
where a total mess.

--
cinap

Re: [9fans] these are release of 9front?

[Richard Miller]

> many drivers needed a rewrite anyway (like usb audio) because they
> where a total mess.

There are plenty of things in Plan 9 still in need of improvement
or even rewriting.  That's why it makes me sad to see our small
community being made even smaller when some of the most skilled
programmers direct their efforts into splintering off their own
little playgrounds instead of helping to make Plan 9 better for
everyone.

Re: [9fans] these are release of 9front?

[lucio]

> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting.  That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of helping to make Plan 9 better for
> everyone.

<musings>
The key here is "some of the most skilled programmers".  Let's not be
too concerned with the "loss", I think it's important for
experimentation to take place quite literally outside the box, the box
is still there as a reference point.

Thing is, in a volunteer environment, it doesn't matter what problems
are outstanding, what counts is what itches are going to get
scratched.  I think it is inevitable that forks take place, the 9front
people may one day even find themselves in your shoes (consider the
Christian Reformation or the *BSDs).
</musings>

++L

Re: [9fans] these are release of 9front?

[Bence Fábián]

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

Since there are a lot of code flow between 9front and 9atom (even sources,
however that's mostly one directional) I would argue that having the
forks even make things better. Erik and Cinap can experiment more
freely and all the changes are available for everyone. Even breaking
driver compatibility worth it, since the kernel is so small anyway. It is
fairly straightforward to change things. Plan9 is an excellent playground
as you put it. It's a good thing everyone can make their own.

-bence


2013/1/8 Richard Miller <9fans@hamnavoe.com>

> > many drivers needed a rewrite anyway (like usb audio) because they
> > where a total mess.
>
> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting.  That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of helping to make Plan 9 better for
> everyone.
>
>
>

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

Re: [9fans] these are release of 9front?

[steve]

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


 i would like a website where i could compare
the labs, distro with 9front and 9atom. something like russ's
plan9 history site. it wouldn't need to show stuff thats the same
just the differences... just at the file level would do for a start.

sadly i don't have the skills but maybe someone
else will think such a thing would be useful.

just idle thoughts from my sick bed.

-Steve


On 8 Jan 2013, at 11:24, Bence Fábián <begnoc@gmail.com> wrote:

> Since there are a lot of code flow between 9front and 9atom (even sources,
> however that's mostly one directional) I would argue that having the
> forks even make things better. Erik and Cinap can experiment more
> freely and all the changes are available for everyone. Even breaking
> driver compatibility worth it, since the kernel is so small anyway. It is
> fairly straightforward to change things. Plan9 is an excellent playground
> as you put it. It's a good thing everyone can make their own.
> 
> -bence
> 
> 
> 2013/1/8 Richard Miller <9fans@hamnavoe.com>
>> > many drivers needed a rewrite anyway (like usb audio) because they
>> > where a total mess.
>> 
>> There are plenty of things in Plan 9 still in need of improvement
>> or even rewriting.  That's why it makes me sad to see our small
>> community being made even smaller when some of the most skilled
>> programmers direct their efforts into splintering off their own
>> little playgrounds instead of helping to make Plan 9 better for
>> everyone.
> 

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

Re: [9fans] these are release of 9front?

[erik quanstrom]

>  i would like a website where i could compare
> the labs, distro with 9front and 9atom. something like russ's
> plan9 history site. it wouldn't need to show stuff thats the same
> just the differences... just at the file level would do for a start.

good idea.  for me it's a matter of time.  but i would like
something like this.

- erik

Re: [9fans] these are release of 9front?

[sl]

> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting.  That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of helping to make Plan 9 better for
> everyone.

So far as I know the only projects not sharing all their source
code are semi-official ones.

-sl

Re: [9fans] these are release of 9front?

[Wes Kussmaul]

On Tue, 2013-01-08 at 07:48 -0600, sl@9front.org wrote:
> > There are plenty of things in Plan 9 still in need of improvement
> > or even rewriting.  That's why it makes me sad to see our small
> > community being made even smaller when some of the most skilled
> > programmers direct their efforts into splintering off their own
> > little playgrounds instead of helping to make Plan 9 better for
> > everyone.
>
> So far as I know the only projects not sharing all their source
> code are semi-official ones.

The big leaps happen when someone with a different set of assumptions
from those of the creators of a thing see it fulfilling a different
function. Forking is messy, as are inflection points.

Re: [9fans] these are release of 9front?

[cinap_lenrek]

what would you suggest to improve that situation?

for me, 9front is a great motivator and learning exercise and
keeps me from cutting myself because of all that plan9 drama
and stagnation. many bugs where fixed in plan9 as a result
of that work.

--
cinap

Re: [9fans] these are release of 9front?

[cinap_lenrek]

i mean, dont worry about us. we'r not intending to be a burden
for the plan9 community. we dont ask for help on anything. we made
a process. we merge in changes from the various forks out there.
we test stuff on our own. we dont get into long pointless debates
about how stuff should be done. we just do it. sorry for all the
people asking on 9fans about 9front stuff.

--
cinap

Re: [9fans] these are release of 9front?

[David Leimbach]

I think you guys should keep doing what you do.  Different people have different reasons and motivations for what they do.  These do not always line up well to form a totally free-from-fragmentation community.  That we all still share 9fans is a good way to keep up with the different efforts too.

I like that 9front is around and pushing things a little differently.  The mainline can take what they think is useful right?  I see no issues.

Sent from my iPhone

On Jan 8, 2013, at 6:33 AM, cinap_lenrek@gmx.de wrote:

> i mean, dont worry about us. we'r not intending to be a burden
> for the plan9 community. we dont ask for help on anything. we made
> a process. we merge in changes from the various forks out there.
> we test stuff on our own. we dont get into long pointless debates
> about how stuff should be done. we just do it. sorry for all the
> people asking on 9fans about 9front stuff.
> 
> --
> cinap
> 

Re: [9fans] these are release of 9front?

[Nemo]

Once thing we could do is try to merge usb stuff so that those are again
compatible in the various 9 flavours out there.

Perhaps the ones to ask about this are Geoff and Cinap (I'm willing to help,
but have not done much on this front since long ago now).

Speaking just for myself, I think the global FS registry is a good thing for usb.
I'm not sure I'd do drivers embedded in usbd now.

At the time, the idea was just to have a single binary (usbd) carrying the usb
stuff. Because using multiple ones implied that the kernel (usbd was at /boot)
had multiple copies of the same libraries for each different binary. So, having a
way to decide which ones to link into usbd and which ones not, seemed a good way.


On Jan 8, 2013, at 3:33 PM, cinap_lenrek@gmx.de wrote:

> i mean, dont worry about us. we'r not intending to be a burden
> for the plan9 community. we dont ask for help on anything. we made
> a process. we merge in changes from the various forks out there.
> we test stuff on our own. we dont get into long pointless debates
> about how stuff should be done. we just do it. sorry for all the
> people asking on 9fans about 9front stuff.

Re: [9fans] these are release of 9front?

[Richard Miller]

> At the time, the idea was just to have a single binary (usbd) carrying the usb
> stuff. Because using multiple ones implied that the kernel (usbd was at /boot)
> had multiple copies of the same libraries for each different binary.

When we worry about multiple copies of the same library code, sometimes the
answer is to abstract the library functionality into another fileserver.
Is there a way we could invent another usb driver layer to do that?

Re: [9fans] these are release of 9front?

[mveety]

On Tuesday, January 08, 2013 19:38:03 Richard Miller wrote:
> > At the time, the idea was just to have a single binary (usbd) carrying
the
> > usb stuff. Because using multiple ones implied that the kernel (usbd
was
> > at /boot) had multiple copies of the same libraries for each different
> > binary.
> When we worry about multiple copies of the same library code,
sometimes the
> answer is to abstract the library functionality into another fileserver.
> Is there a way we could invent another usb driver layer to do that?

I don't see how making another usb stack would be a good idea. We
already have enough.

--
Veety

Re: [9fans] these are release of 9front?

[erik quanstrom]

> I don't see how making another usb stack would be a good idea.  We
> already have enough.

the current usb stack can't do some things it needs to be able to
do.  it's particularly terrible at dealing with devices with scheduling
requirements.  and it doesn't handle xhci.

- erik

Re: [9fans] these are release of 9front?

[Matthew Veety]

> the current usb stack can't do some things it needs to be able to
> do.  it's particularly terrible at dealing with devices with scheduling
> requirements.  and it doesn't handle xhci.
> 
> - erik
> 

Well can't we just fix the problems with the current one? Most of the work is already done. I don't see why we can't just use that. 

Re: [9fans] these are release of 9front?

[Federico G. Benavento]

I don't think erik was suggesting a rewrite, just improving it…

btw, in case anyone cares, I'm with richard on this.

On Jan 8, 2013, at 5:54 PM, Matthew Veety <mveety@gmail.com> wrote:

> 
>> the current usb stack can't do some things it needs to be able to
>> do.  it's particularly terrible at dealing with devices with scheduling
>> requirements.  and it doesn't handle xhci.
>> 
>> - erik
>> 
> 
> Well can't we just fix the problems with the current one? Most of the work is already done. I don't see why we can't just use that. 

---
Federico G. Benavento
benavento@gmail.com

Re: [9fans] these are release of 9front?

[cinap_lenrek]

the lib we'r talking about isnt that big.

term% wc /sys/src/cmd/nusb/lib/*.c
    525    1635   10760 /sys/src/cmd/nusb/lib/dev.c
    176     519    3429 /sys/src/cmd/nusb/lib/dump.c
    272     857    6144 /sys/src/cmd/nusb/lib/parse.c
    973    3011   20333 total

--
cinap

Re: [9fans] these are release of 9front?

[Richard Miller]

> the lib we'r talking about isnt that big.
>
> term% wc /sys/src/cmd/nusb/lib/*.c
>     525    1635   10760 /sys/src/cmd/nusb/lib/dev.c
>     176     519    3429 /sys/src/cmd/nusb/lib/dump.c
>     272     857    6144 /sys/src/cmd/nusb/lib/parse.c
>     973    3011   20333 total

I tried the experiment of un-embedding all the usb drivers
(kb, disk, ether, serial) from usbd and putting them separately
into /boot.  Here's the size difference (ARM):

--rwxrwxr-x M 15 miller sys 2542753 Jan 12 13:36 9pi
--rwxrwxr-x M 15 miller sys 2042801 Jan 12 09:57 9pi-embed

Re: [9fans] these are release of 9front?

[erik quanstrom]

On Sat Jan 12 08:51:16 EST 2013, 9fans@hamnavoe.com wrote:
> > the lib we'r talking about isnt that big.
> >
> > term% wc /sys/src/cmd/nusb/lib/*.c
> >     525    1635   10760 /sys/src/cmd/nusb/lib/dev.c
> >     176     519    3429 /sys/src/cmd/nusb/lib/dump.c
> >     272     857    6144 /sys/src/cmd/nusb/lib/parse.c
> >     973    3011   20333 total
>
> I tried the experiment of un-embedding all the usb drivers
> (kb, disk, ether, serial) from usbd and putting them separately
> into /boot.  Here's the size difference (ARM):
>
> --rwxrwxr-x M 15 miller sys 2542753 Jan 12 13:36 9pi
> --rwxrwxr-x M 15 miller sys 2042801 Jan 12 09:57 9pi-embed

on rasperry pi, can't one  just run usbd & usb/* as regular programs,
since usb is not required to boot?

- erik

Re: [9fans] these are release of 9front?

[Richard Miller]

> on rasperry pi, can't one  just run usbd & usb/* as regular programs,
> since usb is not required to boot?

Don't forget you need usb for keyboard and ethernet, which
often come into play during the boot process.

Actually the pi is a special case because the fat partition on the
SD card is guaranteed to be there (for the GPU to boot from).  We
could have just dossrv in /boot and load everything else from SD.
But that's starting to look too much like initrd ...

/boot is simple, and RAM is cheap, even on the pi.

Re: [9fans] these are release of 9front?

[Richard Miller]

> Actually the pi is a special case

... and I was just quoting size figures for that because I had them handy.
The question of embedding things in usbd applies to other architectures too.

I find the embedding problematic, not because of memory size, but because
it gets in the way when trying to develop and test different versions of
drivers.  That's why I added the 'noauto' command to /dev/usbdctl (must
document it soon).

Also the decision of what to auto-start can depend on the machine
configuration, and it feels wrong to have that information compiled in
to the kernel or even into the usbd command.  It seems to me that it
should be in some sort of script or config file that can be varied
per machine or class of machine.

Re: [9fans] these are release of 9front?

[erik quanstrom]

On Tue Jan  8 05:53:23 EST 2013, 9fans@hamnavoe.com wrote:
> > many drivers needed a rewrite anyway (like usb audio) because they
> > where a total mess.
>
> There are plenty of things in Plan 9 still in need of improvement
> or even rewriting.  That's why it makes me sad to see our small
> community being made even smaller when some of the most skilled
> programmers direct their efforts into splintering off their own
> little playgrounds instead of helping to make Plan 9 better for
> everyone.

i agree with this.  i am unhappy with the current state of things,
too.

however, i find most of the things i've done are not interesting to
all folks.  so what to do: (a) discard the work, or (b) keep a
difference.  suppose you need that bit to do your job?  suppose
the difference helps someone's machine boot?  and once
you have a few "required" diffs, then it's easy for the trivial to creep
in.  especially in the face of any reformatting.

i think that it's possible for someone like you, who is in fact skilled,
to navigate these dilemmas with well-crafted changes.

but i have not been able to.

- erik