the lib we'r talking about isnt that big.
term% wc /sys/src/cmd/nusb/lib/*.c
5251635 10760 /sys/src/cmd/nusb/lib/dev.c
176 5193429 /sys/src/cmd/nusb/lib/dump.c
272 8576144 /sys/src/cmd/nusb/lib/parse.c
9733011 20333 total
I tried the experiment
On Sat Jan 12 08:51:16 EST 2013, 9f...@hamnavoe.com wrote:
the lib we'r talking about isnt that big.
term% wc /sys/src/cmd/nusb/lib/*.c
5251635 10760 /sys/src/cmd/nusb/lib/dev.c
176 5193429 /sys/src/cmd/nusb/lib/dump.c
272 8576144
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
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
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).
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
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
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
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
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
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
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
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
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
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
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
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
On Tue, 2013-01-08 at 07:48 -0600, s...@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
On Tue Jan 8 05:53:23 EST 2013, 9f...@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
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,
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.
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
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
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 mve...@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
the lib we'r talking about isnt that big.
term% wc /sys/src/cmd/nusb/lib/*.c
5251635 10760 /sys/src/cmd/nusb/lib/dev.c
176 5193429 /sys/src/cmd/nusb/lib/dump.c
272 8576144 /sys/src/cmd/nusb/lib/parse.c
9733011 20333 total
--
cinap
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
26 matches
Mail list logo
