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

[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

Post by 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

[s***@9front.org]

Post by Francesco Cardi
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

[Richard Miller]

Post by Francesco Cardi
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).

[c***@gmx.de]

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

[Richard Miller]

Post by c***@gmx.de
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?

[c***@gmx.de]

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

[Richard Miller]

Post by c***@gmx.de
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.

[l***@proxima.alt.za]

Post by Richard Miller
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

[Bence Fábián]

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

Post by Richard Miller

Post by c***@gmx.de
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.

[steve]

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

Post by Bence Fábián
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

Post by Richard Miller

Post by c***@gmx.de
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.

[erik quanstrom]

Post by steve
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

[s***@9front.org]

Post by Richard Miller
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

[Wes Kussmaul]

Post by s***@9front.org

Post by Richard Miller
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.

[c***@gmx.de]

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

[c***@gmx.de]

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

[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

Post by c***@gmx.de
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

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

Post by c***@gmx.de
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.

[Richard Miller]

Post by Nemo
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?

[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

[Matthew Veety]

Post by erik quanstrom
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]

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

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

Post by Matthew Veety

Post by erik quanstrom
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
***@gmail.com

[m***@gmail.com]

Post by Richard Miller

Post by Nemo
At the time, the idea was just to have a single binary (usbd) carrying

the

Post by Richard Miller

Post by Nemo
usb stuff. Because using multiple ones implied that the kernel (usbd

was

Post by Richard Miller

Post by Nemo
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

Post by Richard Miller
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

[c***@gmx.de]

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

[Richard Miller]

Post by c***@gmx.de
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

[erik quanstrom]

Post by Richard Miller

Post by c***@gmx.de
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
--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

[Richard Miller]

Post by erik quanstrom
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.

[Richard Miller]

Post by 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.

[erik quanstrom]

Post by Richard Miller

Post by c***@gmx.de
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