Ok, now that the thesis is signed, I feel ready to release my work on
streaming for 9P, as outlined in my talk at IWP9; things have changed
a lot since that talk, but the general idea remains the same. The
repository at https://bitbucket.org/floren/tstream/ contains my code
and the thesis documents
On Fri, Jan 7, 2011 at 5:52 PM, erik quanstrom wrote:
> okay, so there's some sort of bug. what kind of output
> would you like. this is for the kw ehci.
>
Hmm, if it is a bug it is on purpose I think. You are right
it could probably change to show vid/did.
All is started by startdev in
/sys/s
On Fri Jan 7 11:51:23 EST 2011, n...@lsub.org wrote:
> Ah.
> A root hub is an invention of the usb std.
> There's no such thing. It's the controller.
> It can be that usbd does not write vid/did for root hubs, perhaps.
>
> I've not seen a root hub in a keyboard. If it's a usb keyboard, it can't b
Ah.
A root hub is an invention of the usb std.
There's no such thing. It's the controller.
It can be that usbd does not write vid/did for root hubs, perhaps.
I've not seen a root hub in a keyboard. If it's a usb keyboard, it can't be
a root hub, because you have to plug the kbd into a port, which
> Anybody have recent drawterm binary for windows xp? mingw32 is not
> agreeing with me right now.
from the current source, plus a fix for windows:
ftp://ftp.quanstro.net/other/drawterm/drawterm.exe
ftp://ftp.quanstro.net/other/drawterm/drawterm-macosx-10.5
ftp://ftp.quanstro.net/other/drawterm/d
>> ep3.0/ctl:hub csp 0x09 ports 3 'Mitsumi Electric' 'Hub in Apple Extended
>> USB Keyboard' ehci
>I do see vids/dids just not for hubs.
perhaps i misunderstand what is ment by a "root hub".
i thought that ment that it was a hub that usb(3) invented.
a hub in a keyboard can't be a root hub,
I do see vids/dids just not for hubs.
-
Curiosity sKilled the cat
G.
On Jan 7, 2011, at 3:28 PM, Nemo wrote:
> i think usbd added that.
> iirc it should do it. I'll take a look anyway. maybe the code was gone
> in some change...
>
> On Jan 7, 2011, at 2:12 PM, erik quanstrom wrote:
>
>> it
i think usbd added that.
iirc it should do it. I'll take a look anyway. maybe the code was gone
in some change...
On Jan 7, 2011, at 2:12 PM, erik quanstrom wrote:
> it doesn't seem to be available in anyone's control files.
>
> usb(3) says
>
>This may result from the read of an endpo
it doesn't seem to be available in anyone's control files.
usb(3) says
This may result from the read of an endpoint control file:
(the first line is wrapped to make it fit here)
enabled control rw speed full maxpkt 64 pollival 0
samplesz
On Fri, 7 Jan 2011 10:51:56 +0100
Ciprian Dorin Craciun wrote:
> :) I've kind of feared that this is the reason... :)
>
> But still how do people handle the issue?
I guess in most cases it is ok to ignore the slight waste of CPU-time.
And i guess people just ignore it. After all it cos
On Fri, Jan 7, 2011 at 11:25, erik quanstrom wrote:
> the code has its reasons. from mk.c:/^outofdate
>
> /*
> * Treat equal times as out-of-date.
> * It's a race, and the safer option is to do
> * extra building rather than not enoug
the code has its reasons. from mk.c:/^outofdate
/*
* Treat equal times as out-of-date.
* It's a race, and the safer option is to do
* extra building rather than not enough.
*/
return node->time <=
Hello all!
I've played today with mk (from plan9ports), and I thin I've
stumbled upon the following issue: if both the build of a prerequisite
and the target itself is less than a second (the same second), then mk
believes it must remake the target when invoked a second time.
See belo
13 matches
Mail list logo
