[9fans] /dev/etherfile
/sys/src/cmd/usb/ether/ether.c says * BUG: This should use /dev/etherfile to * use the kernel ether device code. Which sounds promising, but I can't seem to find any references to etherfile anywhere else. Does it exist? tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] Help with two small shared file servers
> > > Is 9p suitable for this? How will the 40ms latency affect 9p > > > operation? (I have 100Mbit). > > > > With a strict request/response protocol you will get no more > > than 64KB once every 80ms so your throughput at best will be > > 6.55Mbps or about 15 times slower than using HTTP/FTP on > > 100Mbps link for large files. [John, what was the link speed > > for the tests in your thesis?] > i calculate 1/0.080s/rt * 64*1024 = 819 kbytes/s. (i think your > conversion from mbits/s to bytes/s is faulty.) 819 kbyte/s just about than 6.55 Mbps, at 8 bits a byte. and 64*1024/0.08 * 8 = 6553600 or are you talking about something else entirely? tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] SIP
> Anyone working on or have a simple SIP router/proxy for Plan9? As of > today I will no longer waste days of my life dealing with the > abomination that is Asterisk. I would also love to see a SIP implementation for Plan 9, I've contemplated it a number of times, but the sheer volume of SIP RFCs is not encouraging! And porting something like SER (never Asterisk) appears even harder. That said, I've thought a good bit about a sensible way to implement a SIP proxy, and I'll be thinking about it a good bit more now... -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] Making read(1) an rc(1) builtin?
(right, sorry erik for the double)
> i hate to be pedantic,
By all means, please be pedantic, I was flat wrong.
>ifs is not a list; it is a set of characters like strpbrk(2).
And it matches [$ifs]+ which is the other piece I always forget.
> for(line in `{ifs=$nl cat}){...}
That is exactly what I was saying, thank you. That's what I get for
spending the last few days writing in php, sigh.
> as per plan 9 tradition, the first non-option terminates
> option processing. lindon's echon is not required. giving
> echo -n as its first argument works fine.
What I thought smiley was referring to is when the first argument is
inteded to output -n, but doesn't. What I gave obviously puts an extra
space in (I guess I was a bit fuzzy earlier), echo -n $it^$nl works if
$it is not a list. I've never seen this be a problem in practice myself.
--
All original matter is hereby placed immediately under the public domain.
Re: [9fans] Making read(1) an rc(1) builtin?
> One thing that has come to concern me about rc(1) is that read(1) is
> not a "builtin" command.
The general idea here is that forking a new process is not usually
(ever?) the bottleneck, if you have a script that needs to run faster,
there's other overhead to trim first, and if you really need to, you can:
(giving up line at a time response).
ifs=($nl)
lines=`{cat}
for($lines as $line){...}
There isn't any such trick (that I know) for test, but how much is it
slowing you down?
> I'm also a bit stumped by the fact that rc(1) doesn't have anything
> analogous to bash(1)'s string parsing operations: ${foo#bar},
> ${foo##bar}, ${foo%bar}, ${foo%%bar}, or ${foo/bar/baz}.
I could never remember what these did, except the last one.
> Is there any way to extract substrings (or single characters) from a
> string in rc(1) without having to fork a dd, awk, or sed?
Sure, for some things, except it uses cat! Without any forking, I don't
know (see below).
On the other hand, echo -n is a wart. I wonder, does echo '' -n work?
(My plan9 machine is off and far away.)
On a more friendly note. Hi, I think I know you slightly, telephones.
Tristan
--
All original matter is hereby placed immediately under the public domain.
Re: [9fans] sound, graphics, tuner
> To start with, audio(3) seems to support soundblaster-16-compatibles. > What about others? to my knowledge you have: soundblaster comptibles, usb thingys, and kirkwood. (the kirkwood driver is in my contrib, it's my 1½st driver, so beware. oh, and record isn't tested (and I would guess doesn't work)). hum, drawterm too (which is a bit of a corner case). that said, the audio interface is pretty simple, and if your card is reasonable (not my laptop) i doubt it would be hard to write, the mixing interface has a lot of faces (which is why i havn't annoyed geoff with the kw yet), but that won't matter for you. > How do I find from within plan 9 what soundcard/hardware I have? pci(1)? enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] kw audio -- /dev/audio and friends
> I am guessing the io in audio does not mean in/out. i was just changing the name to not overlap, and bacronyms are fun. > I think audioinctl audiooutctl is a little bit more readable. agreed. -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] kw audio -- /dev/audio and friends
>> multiple inputs or outputs? if so, my first pass would be do something >> like what #l does: #l0, #l1, &c. > Wouldn't it be better to use #A0, #A1, ... for the case of multiple > audio devices instead of multiple in/outs in one device? that would make sense to me, though if there's a ethernet card that had multiple interfaces in an analogous way, #l0, #l1 would probably be used. > I don't see why control^(1 2 3 4 5 6) or in1, out1 are so ugly > (specially considering that this is just a potential "problem"). the cs42l51 (the codec used on the openrd) audioctl looks like this: power in 1 0 1 pgapower in 1 0 1 boost in 0 0 1 micdiff in 0 0 1 micbias in 0 0 3 1 micboost0 in 0 0 1 micboost1 in 0 0 1 gain0 in 0 -6 24 1 gain1 in 0 -6 24 1 atten0 in 0 -96 0 1 atten1 in 0 -96 0 1 vol0 in 0 -103 24 1 vol1 in 0 -103 24 1 mute0 in 0 0 1 mute1 in 0 0 1 power out 1 0 1 hpgain out 3 0 7 1 vol0 out 0 -103 24 1 vol1 out 0 -103 24 1 mute0 out 0 0 1 mute1 out 0 0 1 treble out 0 -21 24 1 bass out 0 -21 24 1 volume0 out 0 -204 12 1 volume1 out 0 -204 12 1 mix0 out 0 0 3 mix1 out 0 0 3 with my current incarnation that becomes: audictl: power 0 1 1 pgapower 0 1 1 boost 0 1 0 micdiff 0 1 0 micbias 0 1 0 micboost 0 1 0 0 gain -6 24 0 0 atten -96 0 0 0 vol -103 24 0 0 mute 0 1 0 0 audoctl: power 0 1 1 hpgain 0 7 3 vol -103 24 0 0 mute 0 1 0 0 treble -21 24 0 bass -21 24 0 volume -204 12 0 0 mix 0 3 0 0 to me, that is ugly, without in1 and out1. ugly enough to talk about change, maybe not ugly enough to change. volume is fairly nice: (except with percentages of the range) power in 1 out 1 pgapower in 1 boost in 0 micdiff in 0 micbias in 0 micboost in 0 0 hpgain out 3 gain in 0 0 atten in 0 0 vol in 0 0 out 0 0 mute in 0 0 out 0 0 treble out 0 bass out 0 volume out 0 0 mix out 0 0 and easially extendable: vol in 0 0 0 0 0 0 out 0 0 0 0 0 0 out1 0 0 0 0 0 0 but it doesn't give the ranges. ? vol -103 24 in 0 0 out 0 0 which looks liable to break things (out being optional). tristan (with apologies for such a long post) -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] kw audio -- /dev/audio and friends
> Anthony: > The one for audioctl is reasonably regular and comprehensive; it'd be > nice to standardize our audio interfaces around that. my concern with audioctl is multiple channels. for now control-left and control-right are fine (if clunky), with 5.1 (or 7.1) audio that becomes control^(1 2 3 4 5 6), yuck. maybe we should worry about that when we get there, but as there are still very few drivers, the impact is less now. the other problem with both volume and audioctl will come with multiple streams. in1 and out1 might work, but it starts to look ugly. usbaudio appears to ignore multiple inputs or outputs. > "deprecation" in unix is a mess, where things can stay "deprecated" for > ages. it'd be nice to be able to say "/dev/volume (or /dev/eia0status) > was a mistake; here's a backwards-compatible improvement, and the old > stuff goes away in 6 months." > Skip: > would it be hard to provide the backward compatibility via a user fs -- > at least until apps are updated to the new structure? that was exactly what i was planning to write. if audio stops working running a compatibility fs isn't a big deal. but for anything involved in the access to the system... it can be. (anybody have network over audio?) tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] kw audio -- /dev/audio and friends
> - why do you assume that the old interface was not considered > sufficient? if volume were sufficient, there was no reason to add audioctl. > - if you read usb(4) the first sentence on usb audio notes the > interface is backwards compatable. it notes that the names are backwards compatable, but audio only accepts writes (or so it appears). in terms of the volume file, yes. > is your interface backwards compatible with the other two? my interface does not conflict with either of the other two (the filenames do not overlap), and mapping aud[io]ctl to volume is trivial, unless multiple channels exist, which volume cannot express. that said, i havn't written the backwards compatibility yet. tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] kw audio -- /dev/audio and friends
> Changing a device's file format in a backwards-incompatible way > is not something to be done lightly. In addition to changing all > drivers you'd have to change every user program that reads from > or writes to them, even ones that you don't know exist. i am not offering to change the interface, but to implement a simpler third interface (as usbaudio implements volume). poor diction on my part. the point is that there are currently two semi-incompatable interfaces, do people consider the current two adequate? (apparently volume was not, and i don't consider audioctl to be). and what do other people think about an alternative? tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] kw audio -- /dev/audio and friends
i've been working on an an audio driver for the kirkwood for a while now, indeed it's been working well for a while now. at this point i'm mostly struggling to figure out the mixer/controls/codec filesystem interface. if any of this is incorrect, please correct me. the soundblaster driver has audio for data and volume for control: name [in l r] [out l r] usb/audio has audio and audioin for data and audioctl for control: name (in|out) val min [max [res]] with writes looking like volume as yet, i have audio and audioin with audioctl and audioinctl: name min max( val)+ writes: name( val)+ mostly this just feels better to me. it has both single and multiple values, it can handle cards with more than one channel in or out (not that i'm working with one), and it's simple. but it doesn't indicate card-wide controls (i have a few), and it's yet another incompatable interface. do any of you folks have opinions on these interfaces? i would like to use a simple and extendible interface for the kirkwood driver, and am willing to convert the soundblaster and usb drivers and sound programs (though i don't have the hardware to test). tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] Sheevaplug - USB working? Just checking
> Mouse and keyboard support should be trivial to add and will come once (if) > video is working on the Guruplug Display or OpenRD. This could take a long > while, since the video controller is undocumented (there isn't even Linux > driver source available). There is (or maybe are two) X11 drivers available... though there isn't much talking about it, the first one at least supported the Z11 (xg27 core) at one point. http://cgit.freedesktop.org/xorg/driver/xf86-video-xgi/ and maybe? http://cgit.freedesktop.org/xorg/driver/xf86-video-xgixp/ enjoy, Tristan -- All original matter is hereby placed immediately under the public domain.
Re: kw I²C
eric quanstrom: > if i read the marvell specification correctly, it uses i²s, not i²c. > wikipedia has a pointer to the phillips specification. It uses i²s to for the data (sound) transport. the control for the codec is seperate, the codec is a cs42l51, which has an i²s interface for data and either an i²c or spi interface for control, with the spi write-only. Bankim Bhavsar: > Though Immediate Command/Response Interface should work, CORB/RIRB is > the recommended way to send/receive commands/responses from the codec. Reading the datasheet of the codec, I havn't found any mention of CORB or RIRB, so I would hazard a guess that that's not what I want. But still, what is CORB/RIRB? In light of further digging, the functional specification does talk about "TWSI Bus Operation". twsi ≅ i²c. I guess I'll work on that now. Which, according to the openrd schematics, connects to the audio codec and the SMBus connector. ... tristan -- All original matter is hereby placed immediately under the public domain.
kw I²C
I'm working on a audio driver for kw (openrd) as a warmup for other more useful drivers (do something easy before something hard), and I've come to the point where to do anything more requires talking to the audio codec. According to various linux patches, this is done over I²C. Has anyone done anything with I²C, is it used for anything else? The kirkwood functional specification does not mention it (at least so far as I can see in the copy I have). Elseways I'll scrounge around some more. Thoughts? tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] plot
Is there any way to take a plot(6) file and output to a file? plot(1) seems not to do that (except maybe something to do with troff?) and nothing else appears to read them. Something along the lines of creating a big window, plotting, and catting n/window and trimming the border could work, but I'd rather not... Is there a good reason that plot(1) is (semi) interactive and doesn't just leave the display part to page(1)? enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] printing floating point numbers
I'm working on (re)writing some utilies for geospatial work on Plan9, there are lots of floating point numbers (a file outlining the USGS quadrangles for the state of Maine has about 60k). With the current implementation this takes a long time. Maybe I should switch to a binary format (but that's part of what I'm trying to get away from!). Basically, do folks consider it possible to improve speed while keeping or increasing the precision? A very simple implementation is accurate to ~15 digits, the current one is to 18 digits (though there are some rounding errors). In ways it would be nice to print stored numbers exactly. Yet numbers like 2⁻¹⁰²²+2⁻¹⁰⁷⁴ (767 digits) are stored exactly... 2.2250738585072018771558785585789482407880088486837041956131300312119688603996006965297904292212628858639037013670281908017171296072711910355127227413175152199055740043138804567803233377539881639177387328959246074229270113078053813397081653361296447449529789521218979090783852583365901851789618799885150427514782636076021680436220311292700454832073964845713103912225963935608322440623896907276890186717054549275173986589324810401738228328251245795065655738191038008646911615828719989708647293221449796971546706720399791990809160347625980385995424739847678861180095072511543762389603716215171729816011544604359531284325406441938645324905389137795680915804792405099227413854274942620542640408839836919187418172987793340279242767544565229087538682506419718265533447265625e-308 The current implementation just prints the first 18 digits. Thoughts? Tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] NaN, +Inf, and -Inf, constants?
> NaN(2) and Inf(2) are not constant functions. the result depends on > the settings of the fcr (getfcr(2)). Really? My reading of /sys/src/libc/port/nan.c makes me think NaN(2) returns a uvlong value of 0x7ff1, miss I something? On the other hand, the assignment of NaN to a double depends on the fcr. (And on my machine, curiously changes 0x7ff0...1 to 0x7ff8...1). So if I think of enum definitions as assignment, it makes sense, mostly. thanks, tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] NaN, +Inf, and -Inf, constants?
I'm porting PROJ4.3.3 (the cleanest version of proj I could find), and it's a little ugly. One thing leading to another, I am currently centralizing constants, and found that enums can hold doubles (which is quite nice), but I have no way of defining NaN or Inf as a constant, is there such a way? Or is there a way to evaluate constant functions at compile time (eep)? Or I could just use #define (much safer than the above). enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] VIA VT8122 (ethervgbe), 256 packets, and further no PHY
Is anybody else currently using the ethervgbe driver? I'm had some problems with it which don't seem to be caused by my hardware. After receiving 256 packets I was getting: panic: freeb: ref -1; caller pc 0xf01b1754 panic: freeb: ref -1; caller pc 0xf01b1754 Turns out calling freeb was messing things up (so the second time through the block list the data went to bung blocks) and the workaround simple: 537c537 < etheriq(edev, block, 1); --- > etheriq(edev, block, 0); Now, those of you who know more about this than I, are there any side-effects of that? It seems to be working now... I also discovered (from the chipset manual) that the RX ring is apparently limited to 252 entries, but I'vn't made sure those 4 packets were indeed being dropped. I came across the missing PHY message in 9fans, and just wanted to put out there that I've only had the problem in the transition from Linux to Plan 9 (like when I was fetching docs for it), at which point removing power from the computer before booting fixed it. enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
[9fans] Intel 82544EI Gigabit Ethernet (Fiber)
I've several Intel PRO/1000 XF cards that I would like to use. I remember these cards working before, but they don't now. Looking at etherigbe.c, I see 'intergrate fiber stuff back in' in the todo list. Has anybody looked at this recently and know what would be involved? I can muddle around and try to figure out what is happening, but any advice would be swell. % pci -v ... 1.10.0: net 02.00.00 8086/1009 5 0:e304 131072 1:e306 131072 2:000a001 32 Intel Corporation 82544EI Gigabit Ethernet Controller (Fiber) ... Thank you, Tristan -- All original matter is hereby placed immediately under the public domain.
