Re: [9fans] (no subject)
lu...@proxima.alt.za wrote: That's simple pragmatism. Using Plan 9 without some of the Open Source stuff is hard at least for some of us. And there just aren't enough Plan 9 developers to produce alternatives. Considering the number of useful (if poorly implemented) Open Source tools out there, I'm sure I'm not being absurd. What tools do you have in mind? This can be true for useful projects but it is not the case with Autotools, because it is properly implemented as a useless tool. If they wrote their own Makefile.in you can use that or Makefile.am to create a mkfile fairly quickly. There's no need to worry about path searching because of Plan 9 filespace unions. Testing for missing headers/libraries is also pointless as compiling will tell you this. Autotools will not generate portable code, it can only inject code that the author wrote a condition for. effort reward ergo GNU Not Useful
Re: [9fans] Vector graphics device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: I'm looking for some (9p-based ;-p) vector graphics device which allows one to define/manipulate the image as a graph (instead of having an raster image). http://man.cat-v.org/plan_9/3/draw ellipse, line, polygon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt9riQACgkQl3JZTBu3/9m/wgCfWb0zUYS2yslk1d8jnI/7Y/od VyEAn3jYTdeFI0vFTBUmw2IzloupsvoB =1o4B -END PGP SIGNATURE-
Re: [9fans] More on the GO toolchain
lu...@proxima.alt.za wrote: One of the issue I need to fix, further, is that the 386 linker (at least) demands to access the runtime module (runtime.a - I am not yet ready to build this library) and I wonder if there are any suggestions here on how best to eliminate this mandatory requirements without jeopardising compatibility between the GO toolchain and its ability to replace the native Plan 9 toolchain - which is my primary objective at this point. Perhaps the go 8l is not honoring the -l option? I just tried to create a mbr from assembly and it reported the same runtime requirements. A diff between the various sources might be useful since they are similar.
Re: [9fans] More on the GO toolchain
erik quanstrom wrote: ; mk -n mbr.install 8l -o mbr -H3 -T0x0600 -l mbr.8 ls -l mbr cp mbr /386/mbr The go toolchain yields: $ 8l -o mbr -H3 -T0x0600 -l mbr.8 confidence: runtime·morestack not defined ??none??: _rt0_386_plan9: not defined src/cmd/8l/pass.c: symmorestack = lookup(runtime·morestack, 0); if(pmorestack == P) diag(runtime·morestack not defined); src/cmd/ld/lib.c: void libinit(void) sprint(INITENTRY, _rt0_%s_%s, goarch, goos); If you can address these two, I think you can use 8l without the runtime.
Re: [9fans] Petabytes on a budget: JBODs + Linux + JFS
erik quanstrom wrote: i'm speaking for myself, and not for anybody else here. i do work for coraid, and i do do what i believe. so cavet emptor. We have a 15TB unit, nice bit of hardware. oh, and the coraid unit works with plan 9. :-) You guys should get some Glenda-themed packing tape.
Re: [9fans] Blocks in C
Roman V Shaposhnik wrote: On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote: even commodity intel and amd mp offerings are numa. they're not very n, but they're still n. True. But even for those platforms good SMP frameworks are quite difficult to come by. And here I do mean computation, not how to accommodate scalable IO. We have enjoyed our 4x quad system that we mainly use for sparse matrix circuit solvers, though the current algorithms used don't seem to scale well. Instead of trying to run a single simulation on as many cores as possible, we do many different simulations at once. This trend might move us towards more quadratic programming or differential evolution where you are wanting to search a n-dimensional parameter space for optimization.
Re: [9fans] The first annual Hello, World challenge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
andrey mirtchovski wrote:
i have some variations on a theme:
linux, i386: main() { syscall(4, 1, hello world\n, 12); } (~6KB
dynamically linked)
linux, x86: main() { syscall(1, 1, hello world\n, 12); } (~6KB, 4KB
stripped; 2.4megs statically linked, 400KB statically linked and
stripped)
You can also use some alternative libcs for a reduced footprint, or
eliminate libc altogether with some simple inline assembly. GNU is
really bloated.
I'm not sure where one draws the line though, theres also is a lot of
code and memory behind that syscall before anything is seen on the
screen, which could be considered part of the linked code.
One could always poke data into video memory and avoid all that, but
that does not get us the Are you sure? dialog box or status bars that
go from 0 to 100% over and over again.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqLNrUACgkQl3JZTBu3/9naawCdF9Hlx2niYJJpnbT52tLobmU6
btEAmQGuBC629h7Xx7fu6FKD8NE5yRr7
=JBrq
-END PGP SIGNATURE-
Re: [9fans] audio standards -- too many to choose from
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Devon H. O'Dell wrote: This is starting to remind me of two things: 1) The case where this guy did a review of two different audio processors, and labeled the DAC of one as inferior to the other. He posted audio files of the resulting output from one and the other. Except he posted the exact same link for both of them. People commented about how right he was, after allegedly listening to both files. They were the same file. I'm an audiophile, but I know when to quit. 2) A la Tim Newsham and Federico Benavento, less talk more code. I have a mixerfs implementation from several years ago that Kris and I worked on. I'll fix it up once I get AC'97 on my laptop to demonstrate what I mean mixer-wise. Tim said he was working on an interface that resembles what I've discussed publicly here. I don't know if this has been fixed yet: http://jtomaschke.blogspot.com/2009/02/plan9-ac97-driver-bug.html AC97 covers a wide range of chipsets and you might experience the same problems. This leads to: 3) James, if you don't like it, make your own, and kick our asses. I have already changed the audio and other interfaces such as keyboard input to provide more access to the hardware. I have no desire to develop these things other than getting the program to work. So when someone brings up the subject I'm more than happy to try and get them to do the work for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqE/JkACgkQl3JZTBu3/9kZ8ACgjX0ialxITK+V9QvLn2vrJ0y5 qw8AnRH0Y8iRtkcKVFVT/ccpnyMS7/kg =ql0O -END PGP SIGNATURE-
Re: [9fans] audio standards -- too many to choose from
Charles Forsyth wrote: sorry, i did realise. i'm afraid i just couldn't resist slightly misquoting Flanders and Swann's `Song of Reproduction' (High Fidelity). http://www.amazon.com/Complete-Flanders-Swann-Georges-Brassens/dp/B06T4S/ref=pd_sim_b_1 Yes, marketing in general feeds on more is better. I don't have a complex audio chain, but there are some with multiple devices mixing audio and digital. I believe their argument for higher sampling rates is because the analog filters have to cut frequencies higher than Nyquist, so the higher the sampling frequency the less of of a slope the filter has to work on which reduces the noise from the analog side. Or this can be interpreted as being able to use cheaper analog filters for the same noise requirement. However, this field is beyond my competence. From a hardware perspective, I could see how a single 192kHz DAC is cheaper to use than four 48kHz ones. Smaller chip die area or less components to attach. Either way I believe it has to do more with manufacturing costs.
Re: [9fans] audio standards -- too many to choose from
Roman Shaposhnik wrote: On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote: Here's a complete list of audio formats that one can make hardware either generate or accept. Where do you draw the line? This is incorrect, you don't make hardware do anything, the software layer that sits on top of the hardware does this. The SB16 hardware does not support ADPCM and it never will. My list was only there to try and prove the point that Russ has made -- pick a most common format and stick with it. Convert everything else into it. By this logic, I need to have my application to convert CDROM-XA ADPCM audio from a device into PCM just to talk to an interface, which in turn must convert it back into ADPCM to play it back because the DMA transfers to the audio hardware buffer require ADPCM. One thing that strikes me is that if the device interface is designed in a flexible way that allows for arbitrary codings, then it will be easy to layer a userland driver on top of it that extends the API with more encodings that arent supported in hardware. If the interface isnt flexible in this way, then a separate interface will have to be made for such a userland driver... I'm not sure what the value of unifying those two interface is... I don't think I buy this point of view. Gratuitous flexibility is not something Plan 9 is known for, nor should it. IMHO. Why does this idea deserves a gratuitous label? Preventing an application from communicating to the hardware in a native format is complete lack of flexibility. If you do not care about native hardware formats, why choose PCM over ADPCM as a transport? ADPCM is ~3/4 the size of PCM in terms of bandwidth. MPEG audio and probably most telephony codecs use ADPCM, why consider the 1980 RedBook PCM as the holy audio format?
Re: [9fans] audio standards -- too many to choose from
erik quanstrom wrote: My list was only there to try and prove the point that Russ has made -- pick a most common format and stick with it. Convert everything else into it. By this logic, I need to have my application to convert CDROM-XA ADPCM audio from a device into PCM just to talk to an interface, which in turn must convert it back into ADPCM to play it back because the DMA transfers to the audio hardware buffer require ADPCM. the problem with supporting everything the hardware will do is that it's quite expensive in terms of development time. and that is the scarce resource that needs to be optimized. Creative Labs made an EMU10K1x chipset, the x means that it came with no hardware mixer. The software driver had to perform the mixing before sending it to the hardware. A device driver that only exposes what the hardware has is much more simple than one that patches missing functionality in the software driver. However if you are instead suggesting that it will take time to support other formats other than signed 16-bit little-endian samples. I have no problem with a driver developer initially starting there leaving it incomplete. At least someone has the potential to add such support. it also will make the interfaces much bulkier because you have to make accomidations for the quirks of n formats. you're right, there is a cost. simple is expensive. - erik I don't see the complexity, the interface merely needs to allow device drivers to provide the information such as I support x y z, the application can query a features file, select a format and write back through the interface configuring the hardware. The interface need not have any predetermined knowledge of available formats. The only issue would be for each device driver to agree to call the same format by the same name, s8 s16le s24be. To support multiple mix buffers or audio channels, the interface only needs to iterate information provided by the driver. Again, there is no requirement that initial device driver development need support all possible features.
Re: [9fans] audio standards -- too many to choose from
erik quanstrom wrote: I don't see the complexity, the interface merely needs to allow device drivers to provide the information such as I support x y z, the application can query a features file, select a format and write back through the interface configuring the hardware. The interface need not have any predetermined knowledge of available formats. The only issue would be for each device driver to agree to call the same format by the same name, s8 s16le s24be. i think you're ignoring the complexity. suppose we wish to support 10 formats. suppose that i have devices that support all 10 formats. then there are 90 different conversions to do to fill in the gaps. now suppose that we pick a format. then we need to write 10 conversions. also each driver potentially needs 1 conversion. if we want to write things like audio mixers or whatnot in software, we only need to support 1 input and 1 output format. It's a matter of kernelspace vs userspace and freedom. Nothing I have proposed prevents you from using a single format. Nothing I have proposed requires you to implement N formats or conversions. This is because I allow for your freedom to do so in userspace. Rather, your suggestion of forcing a single format, prevents my applications from using other formats, and it requires I implement conversions. This is because you limit freedom by placing a simple interface into kernelspace. If you desire a simple audio server to glue simple audio applications it can be done in userspace, a |filter program can be used by an audio server on top of the device driver. The scope of the complexity of which is completely up to you.
Re: [9fans] audio standards -- too many to choose from
Devon H. O'Dell wrote: 2009/8/13 James Tomaschke ja...@orcasystems.com: Rather, your suggestion of forcing a single format, prevents my applications from using other formats, and it requires I implement conversions. This is because you limit freedom by placing a simple interface into kernelspace. This is the silliest thing I've seen posted in this thread. No offense intended, but if you choose the highest available sample size and bit rate available to the card, you are not limiting anybody: the limitation becomes the hardware. If that's an issue, get really ridiculously high quality analog devices, and stop being so anal about your perfect ears. How can an application select a higher sample size if the interface to the driver only supports signed 16-bit samples? the limitation becomes the hardware Music App 24...@192khz - #audio 16bit - Hardware 24...@192khz.
Re: [9fans] audio standards -- too many to choose from
Anthony Sorace wrote: James Tomaschkeja...@orcasystems.com wrote: // ...you limit freedom by placing a simple interface into kernelspace. are you serious? Show me how forcing a single sample format on the user increases their freedom in developing audio applications.
Re: [9fans] audio standards -- too many to choose from
Charles Forsyth wrote: Hardware 24...@192khz. the human ear can't hear as high as that still, it ought to please any passing bat! Hi-fi, hi-fi, ... So if i instead said 24...@44.1khz would it make any difference on my argument? please. You are right, however 192kHz means the DAC bandwidth could support 4x 48kHz buffers, which is what it's used for.
Re: [9fans] audio standards -- too many to choose from
Devon H. O'Dell wrote: If hardware is 2...@192, #A is 2...@192 I am not aware that #A allows for 24bit samples, I only see an option speed to set sampling rates. The man page says: Each sample is a 16 bit little-endian two's complement integer. I was only going by what the manpage said, perhaps it's out of date. I really don't understand why this isn't obvious. We're all smart here, why would you think we would suggest something that dumb?
Re: [9fans] audio standards -- too many to choose from
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Cox wrote: I've done audio on a handful of operating systems and all I ever want to do with the card is set it up to play X kHz 16-bit little-endian PCM stereo and then control the volume. The rest can be done from user space. This is exactly what Plan 9's audio driver already does, and I wish the others were so simple. It is simple, and it limits you simple applications. Having to set the sampling format or rate has never been a problem, in fact it is a requirement. The sample and format are chosen by the application based on what the hardware internally supports to eliminate any sample or rate conversion overhead. Low latency is very important for many audio applications. By analogy, Plan 9's kernel gives user space access to the raw disk bytes. It doesn't implement the interpretation of those bytes as 9660, fat, ext2, kfs, venti, or other disk file formats. That can be done better and more easily in user space. This is an incorrect analogy, audio hardware (DACs/ADCs/DSPs) are engineered to function on a unit of information (sample) which varies between audio hardware. Perhaps if all audio hardware were SoundBlaster-16s then the audio(3) interface would make sense. Then there's the whole topic on multiple hardware mix buffers or multiple channels. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqDPh8ACgkQl3JZTBu3/9mdKwCeMT59l/zBLLTB3SgjaIyZzguO d+sAn0KnZzA4zURrQnz1xTQwbXuV90f8 =1h8x -END PGP SIGNATURE-
Re: [9fans] Unexpected 8c warning message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ethan Grammatikidis wrote: I just don't like parsing a for statement, it's rarely clear and usually ugly to my eyes. Writing a parser to parse a for statement is slightly more involved as well. However I was commenting on how the compiler seems to handle a do/while properly so it might be possible to get for- and while-loops to avoid reporting the false warning with some effort. I still use for(;;) instead of while(1) ever since I saw compilers emit machine code that moved $1 into a register followed by a compare. Most modern compilers do no do this anymore but old habits die hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqB7csACgkQl3JZTBu3/9lgjACgsrd39mxz4Ak6x9cY4iUeK0+A gnUAnRwbVd/6nkxLW5dtxeoxJnS+Njf/ =Rkj5 -END PGP SIGNATURE-
Re: [9fans] Stuck at partdisk
Devon H. O'Dell wrote: 2009/4/5 ron minnich rminn...@gmail.com: On Sun, Apr 5, 2009 at 12:12 PM, Devon H. O'Dell devon.od...@gmail.com wrote: 2009/4/5 Devon H. O'Dell devon.od...@gmail.com: Ideas? Works fine if I turn off DMA. no need to have DMA on on qemu anyway, so you have a workaround. Except that it's now looking to take about 5 hours to install on my 3 core AMD64 box with 8GB RAM :) You can give KVM a whirl, I have had no problems with DMA using it on a 4x4 Barcelona or an AMD64 X2. Should notice a performance increase from using AMD svm anyways.
Re: [9fans] request for more GSoC project suggestions
Paul Lalonde wrote: I'd like to see a 3D graphics protocol. Then I could run the host on some linux or window or mac box to do the display, and run the graphics app in Plan9, or inferno, or ... A port of vmgl to Plan9 would be nice for this. http://www.cs.toronto.edu/~andreslc/xen-gl/ As for native GL, I'm not sure if there is any hardware option that has enough documentation to implement a driver. I was considering digging up my old 3dfx card for a miniGL to play with.
Re: [9fans] looking for opinions on Interprocess communication
Fernan Bolando wrote: I was wondering if you guys have an opinion on the following data communication methods. I would suggest using whatever method keeps the code simple. You can worry about optimization later when you have some data on performance. It will be easier to optimize starting from a simple implementation than from a more complex best-guess.
[9fans] Raw Input Driver
Greetings all, I have created a very simple input driver that interleaves keyboard and mouse events for an interactive program I am working on. I have tried to keep it as simple as possible, just a single callback in pc/kbd.c and port/devmouse.c. The only goal I had was to capture keys like shift and press/release events while keeping them in order with mouse events which is working great. CONS(3) states: If the string rawon has been written to the consctl file and file is still open, cons is in rawmode. Yet I have not had much luck here, the only way I have been able to prevent echoing has been to use the event library einit(Ekeyboard). So I have duplicated the code from libdraw/event.c yet it still does not work. Any ideas on what I am missing? Regards, /james
Re: [9fans] Raw Input Driver
I am also looking for advice on what people might like for the
interface, right now I am using:
struct InputEvent {
intmsec;
unsigned short type;
unsigned short code;
intvalue;
};
type, keyboard or mouse,
keyboard code, key down or key up
keyboard value, scancode
mouse code, buttons, dx or dy
mouse value, button bits, dx or dy values
lu...@proxima.alt.za wrote:
I have created a very simple input driver that interleaves keyboard and
mouse events for an interactive program I am working on. I have tried
to keep it as simple as possible, just a single callback in pc/kbd.c and
port/devmouse.c.
I've been thinking along the same lines, I'd like to see more
seamlessness between mouse and keyboard.
++L
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
I would suggest the compiler as well, students are probably more familiar with compiler concepts and it will probably be easier to mentor. In the future, the porting work can be distributed over the community anyways. ron minnich wrote: Is a mips-64 port a reasonable GSOC project? The person doing it could not come in cold, but there is a starting point it seems. In spite of my earlier suggestion, I have to agree with Russ. Gcc and its utils are a daily headache for me, I'd rather just get a mips-64 compiler port first. ron
Re: [9fans] AC97 Driver Bug (w/FIX)
Apologies for the vcard, first post noobness.
Re: [9fans] threads vs forks
J.R. Mauro wrote: On Tue, Mar 3, 2009 at 7:54 PM, erik quanstrom quans...@quanstro.net wrote: I should have qualified. I mean *massive* parallelization when applied to average use cases. I don't think it's totally unusable (I complain about synchronous I/O on my phone every day), but it's being pushed as a panacea, and that is what I think is wrong. Don Knuth holds this opinion, but I think he's mostly alone on that, unfortunately. it's interesting that parallel wasn't cool when chips were getting noticably faster rapidly. perhaps the focus on parallelization is a sign there aren't any other ideas. Indeed, I think it is. The big manufacturers seem to have hit a wall with clock speed, done a full reverse, and are now just trying to pack more transistors and cores on the chip. Not that this is evil, but I think this is just as bad as the obsession with upping the clock speeds in that they're too focused on one path instead of incorporating other cool ideas (i.e., things Transmeta was working on with virtualization and hosting foreign ISAs) Die size has been the main focus for the foundries, reduced transistor switch time is just a benefit from that. Digital components work well here, but Analog suffers and creating a stable clock at high frequency is done in the Analog domain. It is much easier to double the transistor count than it is to double the clock frequency. Also have to consider the power/heat/noise costs from increasing the clock. I think the reason why you didn't see parallelism come out earlier in the PC market was because they needed to create new mechanisms for I/O. AMD did this with Hypertransport, and I've seen 32-core (8-socket) systems with this. Now Intel has their own I/O rethink out there. I've been trying to get my industry to look at parallel computing for many years, and it's only now that they are starting to sell parallel circuit simulators and still they are not that efficient. A traditionally week-long sim is now taking a single day when run on 12-cores. I'll take that 7x over 1x anytime though. /james
Re: [9fans] threads vs forks
erik quanstrom wrote: I think the reason why you didn't see parallelism come out earlier in the PC market was because they needed to create new mechanisms for I/O. AMD did this with Hypertransport, and I've seen 32-core (8-socket) systems with this. Now Intel has their own I/O rethink out there. i think what you're saying is equivalent to saying (in terms i understand) that memory bandwidth was so bad that a second processor couldn't do much work. Yes bandwidth and latency. but i haven't found this to be the case. even the highly constrained pentium 4 gets some milage out of hyperthreading for the tests i've run. the intel 5000-series still use a fsb. and they seem to scale well from 1 to 4 cores. Many of the circuit simulators I use fall flat on their face after 4 cores, say. However I blame this on their algorithm not hardware. I wasn't making an AMD vs Intel comment, just that AMD had created HTX along with their K8 platform to address scalability concerns with I/O. are there benchmarks that show otherwise similar hypertransport systems trouncing intel in multithreaded performance? i don't recall seeing anything more than a moderate (15-20%) advantage. I don't have a 16-core Intel system to compare with, but: http://en.wikipedia.org/wiki/List_of_device_bandwidths#Computer_buses I think the reason why Intel developed their Common Systems Interconnect (now called QuickPath Interconnect) was to address it's shortcomings. Both AMD and Intel are looking at I/O because it is and will be a limiting factor when scaling to higher core counts. - erik
[9fans] AC97 Driver Bug (w/FIX)
More info here: http://jtomaschke.blogspot.com/2009/02/plan9-ac97-driver-bug.html This is based on mason's contrib ac97.tgz. I placed my code above the if/elseif to provide it with an initial state in case both tests fail. After this, kvm -soundhw ac97 gave me audio in my virtual environment. /james begin:vcard fn:James Tomaschke n:Tomaschke;James org:Orca Systems, Inc. adr:;;13025 Danielson Street, Suite 106;Poway;CA;92064;USA email;internet:ja...@orcasystems.com title:Snr. Software Engr. tel;work:858.679.9335 tel;fax:858.679.9452 x-mozilla-html:FALSE url:http://www.orcasystems.com version:2.1 end:vcard
