Re: [9fans] GCC/G++: some stress testing
On Mon, Mar 3, 2008 at 4:31 AM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote: > On Sun, 2008-03-02 at 12:34 -0800, Paul Lalonde wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > CSP doesn't scale very well to hundreds of simultaneously executing > > threads (my claim, not, as far as I've found yet, anyone else's). > > I take it that you really do mean "simultaneous". As in: you actually > have hundreds of cores available on the same system. I'm actually > quite curious to find out what's the highest number of cores available > of a single shared memory systems that you, or anybody else has > experienced in practice so far (mine would be 32 == 8 CPUs x 4 cores AMD > Barcelona)? Now even more important question is -- what are the > expectations for, this number in 5 years from now? > Actually, with parts available from AMD you can directly mesh up to 64 sockets, each with (currently) 4 cores, 8 core cpu announced (as MCP in the beginning). And there were available methods for routing HT traffic with number of sockets nearing thousands or tens of thousands. Dunno if they used it directly with cache coherency protocol though. -- Paul Lasek
Re: [9fans] Non-stack-based calling conventions
I've got some time to delve into Fascicle One again and indeed, MMIX doesn't have any stack at all. When you need stack, you implement it yourself. Anyone knows of other CPU's using this method for stack (i.e. no in-built support for stack in memory)? There is stack based on registers, though. On Sat, Feb 16, 2008 at 12:47 AM, Paweł Lasek <[EMAIL PROTECTED]> wrote: > I don't have latest version of fascicle one (MMIX processor > architecture and MMIXAL assembler language, from new version of The > Art of Computer Programming) at hand, so I can't confirm it, but I > remember that MMIX had a special register which implemented a > "border", shifting register numbers to use them for procedure data > separation. > > And as in all RISC architectures, storing as many parameters in the > call stack is the way to go. Especially when you have 256 64-bit > general purpose registers :-) (Now if only someone implemented a sane > architecture using MMIX as main processor...) > > > > > On 2/16/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > > - DOS interrupt function calls use the registers, not the stack. > > - SPARC and MIPS registers are provided to pass parameters. > > > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > > > > >> > > >> The calling conventions I have seen are the ccall, stdcall > > >> (Windows' slightly modified version of the ccall), and pascal. All > > >> of them push parameters on the stack. > > > > > > Take a look at the R-call and S-call conventions used on the IBM > > > System 360 architecture. These machines didn't even have a stack. > > > > > > --lyndon > > > > > > > -- > Paul Lasek > -- Paul Lasek
Re: [9fans] Non-stack-based calling conventions
I don't have latest version of fascicle one (MMIX processor architecture and MMIXAL assembler language, from new version of The Art of Computer Programming) at hand, so I can't confirm it, but I remember that MMIX had a special register which implemented a "border", shifting register numbers to use them for procedure data separation. And as in all RISC architectures, storing as many parameters in the call stack is the way to go. Especially when you have 256 64-bit general purpose registers :-) (Now if only someone implemented a sane architecture using MMIX as main processor...) On 2/16/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > - DOS interrupt function calls use the registers, not the stack. > - SPARC and MIPS registers are provided to pass parameters. > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > > >> > >> The calling conventions I have seen are the ccall, stdcall > >> (Windows' slightly modified version of the ccall), and pascal. All > >> of them push parameters on the stack. > > > > Take a look at the R-call and S-call conventions used on the IBM > > System 360 architecture. These machines didn't even have a stack. > > > > --lyndon > > -- Paul Lasek
Re: [9fans] Installing Plan9 on a DEC Alpha Workstation
On Feb 13, 2008 6:22 PM, devrin talen <[EMAIL PROTECTED]> wrote: > Hi, > > I'm new to plan 9 but am interested in getting it running on an Alpha > 600a workstation that currently runs Redhat 6. I was wondering where I > should look to get started, and if this will be feasible. I've checked > out the website and docs but still have a few questions: > > * It seems that the live cd has only x86 binaries. Is there a version > for the Alpha architecture? > * Are there any known hardware issues with the Alpha port? > > Thanks! > AS600 has an EV5 cpu, not an EV56, so IIRC you might have to clean up some assembler code and add some assembler for drivers to work properly without BWX instructions (This is also a problem for my AS255). Plan9 supported Alpha only by netbooting and only as CPU server, at least this is what I heard (full transcript could be found in archives). In order to get alpha binaries you will have to recompile the system on a machine with working Plan9 installation (VM is fine too) and for starters you will probably need one configured to work as fileserver with alpha binaries. You can find most of required CPU docs on the net, also *BSD might be a good place to look for details about hardware and SRM. If you are lucky enough, you might find somewhere the developer kits for Alpha hardware manufacturers, which contained PALcode and SRM sources (If you find, share them - I doubt there would be copyright problems, given how much time passed since Compaq killed Alpha for Itanic) Unfortunately my time for working on Alpha port is really limited and my AS is in need of parts (It's really hard to get parity FP simms these day, at least here, and 48 MB is not enough). And also my main priority is to get a newer VMS installed on it, so Plan9 will need to wait even more. An interesting thing to try for porting might be DS10, for which someone has been writing an emulator - It would be nice to show a working Plan9 network composed of only Alphas one day :-) -- Paul Lasek
Re: [9fans] A newbie question...
On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Circular cause and consequence is funny. Let me add to this list: > - jpg > - png > - tiff > - PostScript > - TeX (tpic) > - HTML > - Mahjongg, sokoban, sudoku, tetris (games/4s) > - SPARC, MIPS, x64 > - MP3, PCM, OGG (PAC was made at Bell Labs) > - SoundBlaster 16 > > Let me put it this way: > GNU software is good, except for GNU development tools, which, > except for the gcc program itself, are mediocre and break > compatibility (try using a Bell Labs makefile with GNU make). > I'd add to it the fact that autotools source files are hard to make, so many people who are to lazy to do it properly just put the famous (in)sanity check and checks for libs they use. The effect? A simple C program that doesn't rely on anything except for example libpng will check for C, C++, FORTRAN 77 compilers, check if those are from GCC and various other things. Imagine my surprise when I had seen a configure script (for EmacsLisp utility) that only checked for Emacs version and few EmacsLisp files it used - a rare thing IMHO, when >80% of configure running time is for checking for not used software. "CPU cycles are cheap, programmer time is expensive" <--- This doesn't mean that total laziness is appropriate. The best thing about autotools is I think the scheme of running configure - AFAIK mplayer doesn't even use configure for it's script, instead they use their own, which looks the same to end user. And saves a lot of time :-) -- Paul Lasek
Re: [9fans] Nine4Linux [WAS: Glendix?]
On Nov 22, 2007 7:01 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * erik quanstrom <[EMAIL PROTECTED]> wrote: > > have you seen p9p (http://swtch.com/plan9port)? > > Yes, but I'm not yet sure if this is really what I have in mind. > But at least its a good step in that direction. > > I'm intending to trim down uclibc and maybe put the p9p base > library stuff (9P handling, etc) there. This should save us > the glibc overhead. It could be beneficial to talk with the guys behind RSBAC ( http://www.rsbac.org ). While their security model may differ from Plan 9's, their framework should be a fine tool to add proper semantics, like allowing everybody to have custom namespaces or Plan9 capabilities. After all, their system IIRC discards the whole security mechanism from Unix supplying different modules to create whatever policy you want. And glibc should be damned. IMHO, the main library in the system should be a library written for that OS, not some "multi-platform" thingy designed for different system than its main use :p > cu > -- > - > Enrico Weigelt== metux IT service - http://www.metux.de/ > - -- Paul Lasek
Re: [9fans] Re: everything is a directory
On 8/20/07, erik quanstrom <[EMAIL PROTECTED]> wrote: > > * (IIRC) Beagle daemon uses extended attributes to track files that > > were scanned and are not modified - they contain part of it's detected > > metadata, hash and DB pointer > > so, to summarize. beagle is using attributes to extend the file object. > i think the main benefit files (and a filesystem) is exactly that they > are not objects and can't be extended. The beagle example is the weakest, since I don't use it ( it's written in .NET, uses a bunch of weird tools and AFAIK doesn't play well with external storage -- shortly, I'd do it differently :D). > > > > * NTFS discards the Unix concept of a file entirely - what was shown > > before as trouble with Alternate Data Streams is in fact trouble of > > keeping backward compatibility (Internally, NT doesn't have drive > > letters or any of the DOS stuff). A File in NTFS is a MFT entry with a > > bunch of attributes. Those attributes have several types/names > > defined, like DATA for file contents, one for keeping filename (for > > which there are three namespaces: DOS8.3, Windows, POSIX), one for > > legacy DOS attributes (used by the official, backward compatible API), > > one for security data, and others used mostly by system daemons > > (Although NT5+ explorer uses one to hold various comments about files. > > Rarely used by people I think). > > > > I especially like the NTFS implementation, because it allows to use > > NTFS for most Operating Systems without modifying internal structure, > > while making it easy to add "compatibility layer" > > so how does one create a sensible grep utility that operates on an arbitrary > mft entry? I'm not WinAPI expert, so I can' tell you implementation details on Windows, but if you are writing your own API, all you need is to open attribute/iterate over attributes instead of fopen/fread/... As I wrote, they weren't exactly made "for the users" and as long as you don't put vital user data inside, it should not pose problems. The only thing I'd add is that I think NTFS driver should allow 'open'/'read'/'write'/etc on directory with directory structure as it's data field (directories have different type in NTFS, so they don't have the canonical DATA field) If attributes are used properly on NTFS, your grep question changes to "How does one create a sensible grep for file access rights?" in plan9/unix context. AFAIK everyone uses 'stat' for such things instead of grepping FS structures? The biggest problem is exactly the same as the one with Unix signals - people make wrong use of the tools - most of the time, NTFS attributes are only accessed through API calls for the data that is stored inside or by FS driver itself, not directly by apps. On the other hand, it means that I can implement a Plan 9 NTFS variant without remaking FS structures and if I put some dummy data in MFT entries, It will be readable (even writable) by NT, linux, etc. > > As for things that need to work with cp/mv/others, I suggest making > > better file formats or adding metadata in different file. It's not the > > smartest use of Extended Attributes/NTFS attributes :-) > > i think you're missing the real difficulty with attributres. the tools > approach > works precicely because files are not objects and can't be extended. > > if you want a system with extensible object storage and not a filesystem, > i think you need to think about how to add the extension to all tools at > the same time. (or maybe you dispense with the tools approach.) this > doesn't seem like a promising route to me. I said that what is put into attributes should be easily discarded away, so while tools might support copying them, it's up to you to specify that they should. Like the xfstools example before - none of them use eas the way that you should need to modify basic tools (at least i don't see any reason to use them that way). > - erik > I'd sum it this way: I'm all for *wisely* used external attributes - the trouble is the *wisely* part :-) -- Paul Lasek
Re: [9fans] Re: everything is a directory
On 8/20/07, Tom Lieber <[EMAIL PROTECTED]> wrote: > On 8/20/07, Francisco J Ballesteros <[EMAIL PROTECTED]> wrote: > If the problem is stuffing data into a file that was never meant to be > in the file, attributes are a solution. After all, you quote from jsnx > did say, "But where do the oddball intermediaries put their metadata? > ... [They] can't very well stuff album art into your .mp3 files" (or > something like that...). While I don't give a damn about files being directories, I pretty much like Extended Attributes or NTFS files (in NTFS, file is something different than in *nix-like FS or FAT). While I don't like stuffing "persistent" data into EA's (like album art data, icons or similar things), they are fairly useful from system daemon perspective. Since you want examples, I'll give those that I know: * in XFS, several tools use EA's to assign attributes like "DO NOT DUMP" or hierarchical file management data. This data *should* be discarded by normal tools (since cp is creating a new file, and mv only modifes directories but not i-node's EAs) and are of interest only to those system daemons * (IIRC) Beagle daemon uses extended attributes to track files that were scanned and are not modified - they contain part of it's detected metadata, hash and DB pointer * NTFS discards the Unix concept of a file entirely - what was shown before as trouble with Alternate Data Streams is in fact trouble of keeping backward compatibility (Internally, NT doesn't have drive letters or any of the DOS stuff). A File in NTFS is a MFT entry with a bunch of attributes. Those attributes have several types/names defined, like DATA for file contents, one for keeping filename (for which there are three namespaces: DOS8.3, Windows, POSIX), one for legacy DOS attributes (used by the official, backward compatible API), one for security data, and others used mostly by system daemons (Although NT5+ explorer uses one to hold various comments about files. Rarely used by people I think). I especially like the NTFS implementation, because it allows to use NTFS for most Operating Systems without modifying internal structure, while making it easy to add "compatibility layer" As for things that need to work with cp/mv/others, I suggest making better file formats or adding metadata in different file. It's not the smartest use of Extended Attributes/NTFS attributes :-) > -- > Tom Lieber > http://AllTom.com/ > -- Paul Lasek
Re: [9fans] 9fans content
On 8/10/07, ron minnich <[EMAIL PROTECTED]> wrote: > I am looking at this right now, just saw it yesterday: > http://www.uniconsys.com/devkit-ucn2410-c.html > > I learned something sad about the motorola and trolltech "open" > phones. You can get the phone, get the source, build an OS. > > You can't load the OS you build. > > This just dropped them into the bucket for me. Not sure about open > moko, I expect it is similar. They give you JTAG access so you can reprogram it from the lowest level. The only thing that is not 'user-modifiable' is the GSM module (which is packaged into separate IC and is seen as a serial port to the OS). IIRC the 'hacker' kit includes all tools needed to take it apart and has debugging board included :-) The only thing that I don't like is that it has only GSM. That means that although I'd love to play with it, it won't work for example in Japan (where I intent to go, unless Google hires me, which I doubt.) > Too bad. Cell phone companies are a pain. That's the reason behind OpenMoko AFAIK. They wanted to build "a truly open phone". Now, if it only had UMTS/HSDPA. > ron > -- Paul Lasek
Re: [9fans] kvm
On 7/7/07, Paweł Lasek <[EMAIL PROTECTED]> wrote: On 7/7/07, matt <[EMAIL PROTECTED]> wrote: > Well that certainly sounds promising. I've got qemu images already > > Have you come across this open bug : > >http://sourceforge.net/tracker/index.php?func=detail&aid=1672286&group_id=180599&atid=893831 > [cut] I tried the code they put to test for that bug and nothing happened. That's with kvm-24, AMD Turion X2 and linux kernel 2.6.19-suspend2-r1 (From Gentoo). -- Paul Lasek -- Paul Lasek
Re: [9fans] kvm
On 7/7/07, matt <[EMAIL PROTECTED]> wrote: Well that certainly sounds promising. I've got qemu images already Have you come across this open bug : http://sourceforge.net/tracker/index.php?func=detail&aid=1672286&group_id=180599&atid=893831 I haven't seen something like that, however my installation wasn't used much, so it might be still hidden somewhere. I'll try that code the next time I boot it. However those reports are from kvm-12, so I don't know If it will happen under kvm-24... -- Paul Lasek
Re: [9fans] kvm
On 7/7/07, matt <[EMAIL PROTECTED]> wrote: I notice from the archives that people have had success running plan9 on KVM but I don't see it listed http://kvm.qumranet.com/kvmwiki/Guest_Support_Status My dual Opteron 270 dual core box gets built next week and I'm looking at what I can do with it. I can say that Plan 9 works fine under KVM. Just follow Qemu instructions but use the kvm-supplied qemu build. I currently have a cpu/auth server running on KVM. The only drawback is that I can't seem to get scsi working under kvm-24 qemu, which worked fine in kvm-16. matt -- Paul Lasek
Re: [9fans] Re: X11 setup problem
On 6/20/07, Anthony Sorace <[EMAIL PROTECTED]> wrote: however, and this is important, it is *very* *strongly* recommended that you learn to use the system without X11 first. X11 is not part of the distribution for a reason; that port is old and slow, and was never heavily used. no program in Plan 9 depends on, or even wants, X11 in any way. you will find it distracting and frustrating rather than helpful if you aren't familiar with "real" Plan 9 first, as you'll keep expecting things to be there which aren't. And if someone really wants X11, it might be more sensible to port X.Org's kdrive using /dev/draw for framebuffer It might be easier than getting that old port to be usable with modern X11 apps :-) -- Paul Lasek
Re: [9fans] Wireless PCI Card
On 6/7/07, W B Hacker <[EMAIL PROTECTED]> wrote: Paweł Lasek wrote: > However this won't support non-data PCMCIA cards, so it wouldn't help. > I have yet to hear about someone making IDE interface to anything > other than storage, Google will find you some... Granted, the 'bus attached' (PCI) PCMCIA/Cardbus adapter is more flexible. And agreed there is not a lot of stuff marketed that uses IDE for other than HDD or their emulators, but that is convention and sparse interest in doing otherwise, not a technical limitation. An IDE channel is just another 'mildly specialized' parallel port at the hardware level. One can do a great deal with those with a bit of coding. Okey, I meant something that can be easily used without preparing a driver (I haven't seen driver for such a think in Plan9). I know that you can do pretty much everything - the question is when is this level of tinkering sensible. I think that I can remake a K7 motherboard into EV6 Alpha machine with less trouble (Except for making those DDR signals arrive at exact times... then you just need to reflash the bios with SRM :D) Bill -- Paul Lasek
Re: [9fans] Wireless PCI Card
On 6/6/07, W B Hacker <[EMAIL PROTECTED]> wrote: Rodolfo (kix) wrote: > Yes, Plan9 supported hardware. > > In the wiki "Supported hardware" page, I saw some devices (mostly > PCMCIA), but I am not sure if I can find in the shops or if is old > hardware, if is PCI, ... > There are also IDE cable to multi-socket PCMCIA, CF and other card adaptors, some in FDD housings, others just 'loose'. However this won't support non-data PCMCIA cards, so it wouldn't help. I have yet to hear about someone making IDE interface to anything other than storage, and PCMCIA and CF cards have an IDE mode which is used for flash/microdrives. But you can't control WiFi with IDE. HTH Bill -- Paul Lasek
Re: [9fans] Re: [explanations] MBR messed up on installation
On 5/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hello, [cut] TODO: track the Plan 9 sources to see the manipulation done. Found where the hardware description is obtained (for the ATA CHS values at least). Problem of portability (this is i386 specific). Why is fdisk(8) recomputing the absolute sector to put it in a BIOS cylinder boundary (that has almost no sense). And why does it redefines the starting sector of a partition it has neither created nor modified (for the geometry). It seems that this is modified when setting the ACTIVE flag, that is all the record is overwritten, including recomputed CHS and LBA values. At the moment, fdisk also redefines partition numbers, rearranging them as it finds them on the disk (So if you have first partition number 3, then number 1, then number 2, it gets changed to 1-2-3). It would be a fine thing if Plan 9's fdisk would rather follow the way of GNU/BSD fdisk and _NOT_ touch any partition it didn't modify. While the usage of plan 9 named partitions makes it irrevelant to p9, many people have other OS on their hard drive which don't add another layer (like disklabel or LVM) or aren't configured to do so. Booting another OS just to run fdisk isn't a good thing. Pity that I don't have access to a Plan 9 machine (or time) to prepare a patch for this :-/ To be continued. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- Paul Lasek
Re: [9fans] MBR messed up on installation
On 5/24/07, erik quanstrom <[EMAIL PROTECTED]> wrote: > Disk: /dev/rwd0d > NetBSD disklabel disk geometry: > cylinders: 38792, heads: 16, sectors/track: 63 (1008 sectors/cylinder) > total sectors: 39102336 > > BIOS disk geometry: > cylinders: 1024, heads: 255, sectors/track: 63 (16065 sectors/cylinder) > total sectors: 39102336 why is netbsd making up chs numbers? it would seem to me that that is the problem. i'm not sure where the fdisk partition table standard is, so i can't say definatively this is wrong. but it seems like trouble, making up one's on chs numbers. BIOS geometry seems a little off to me, although It is voodoo magick after all... Especially with a ~20 GB drive. It looks like NetBSD placed LBA-like values into it's disklabel, propably received by it's own drivers, while MBR partition table is made up in ... weird way? Maybe it has that weird geometry to allow booting from every partition without using LBA, as BIOS had 1024 cylinders set. Anyway I'd recommend staying away from Plan9 fdisk if you use other OS, especially other than those from MS (And NT might take it badly too). I'd recommend setting Plan 9 partition from BSD or GNU fdisk and then use plan 9 to make it's own partition table in it. -- Paul Lasek
Re: [9fans] thinkpad wifi hardware choice?
On 5/16/07, Gabriel Diaz <[EMAIL PROTECTED]> wrote: hello on the other hand, you could buy a card with a compatible chip (orinoco) and plug it in the Wireless LAN Mini Express Port :), not sure if that works, iirc that mini port was just a pci thing :-? It's PCI-Express equivalent of MiniPCI slot, with 1x signal IIRC (But I could be wrong) I don't know about PCI-Express WiFi cards supported by Plan 9, but an Orinoco+PCI-Ex-PCI bridge should work. Don't know about availability of those. gabi -- Paul Lasek
Re: [9fans] Re: [sources] 20070410: % cat
On 4/13/07, Lyndon Nerenberg <[EMAIL PROTECTED]> wrote: > for 250k messages, either solution is poor. deleting the > first of 250k messages requires rewriting the whole mbox. > dealing with 250k directory entries can be painful, too, > as many fs keep directores as arrays. > > if you have that many messages, you might want an index. ;-) These days I don't find large directories to be a problem. A few months ago I did some performance tests on large directory operations (create, unlink, readdir) on Linux and FreeBSD. For both OSes, directory enumeration times were negligible for the tests I ran (in the vicinity of 200K entries). And with everyone caching directory entries these days, the only real difference between directory I/O and file I/O is the locking overhead for directory modifications. (This all assumes local disk. Throw in NFS and everything implodes.) That's also thanks to improved filesystems. Modern ones (at least in Linux, I don't know about *BSD as I didn't use them that extentively) use weird/complicated/WTF trees to keep directory (and not only) data. I am not sure if HFS+ doesn't use it also for several other things, as at least one of the developers working on it came from Be where he worked on BeFS, which was basically a database with hierarchical interface... I don't know about other fs'es, but I have never had problem with directory entries on XFS. Or anything else, as I never managed to break it despite being designed for UPS-backed servers (It caches very aggressively, especially writes) while ReiserFS gave up very fast :-) BTW, wouldn't XFS be a nice addition to Plan9? Plan9-specific things can be easily put into extended attributes, just make sure that inodes will have larger-than-default size so that xattr access would be blazing fast --lyndon -- Paul Lasek
Re: [9fans] bell-labs website and plan9
On 4/9/07, ron minnich <[EMAIL PROTECTED]> wrote: > As far as an SCM goes, it would be nice to have one, but I'm sure it > has to run in Plan 9. The big problem that I have with hg and my own > vcs is that neither is really suited for maintaining multiple > branches. Are you sure about Hg in this case? The xen tree is about the size of the plan 9 kernel, for sure, and maybe all of /sys/src, and there are lots of Xen trees out there. I have not used Hg enough to say, but my observation is that it has worked well for xen in distributed repo mode. AFAIK, Sun moves the whole OpenSolaris tree (kernel, userspace, docs, EVERYTHING) into Mercurial. They IIRC use "forest" add-on to manage multiple trees (for different parts of the system) at once. I think Hg with it's tree backed up into Venti would be great thing to have :-) And for big projects... I heard something about Vesta, but judging from the webpage it's really complex system and Unix only. ron -- Paul Lasek
Re: [9fans] something evil happening when partitioning a hdd with the plan9 installer
On 4/9/07, John Soros <[EMAIL PROTECTED]> wrote: [cut] In this case, I'd recommend repartitioning with plain linux fdisk and reserve a partition for plan9 using it (Set partition type to plan9, you can check the number using built-in help IIRC), then during plan9 installation just choose that partition and tell plan9 fdisk to don't write anything. And somebody ought to make plan9 bootable from something other than primary partition (The same problem I have with Solaris 10. I could use those 70 GB of hdd in my school computer, but there are not enough primary partition numbers left for it's disklabel...) -- Paul Lasek
Re: [9fans] myricom 10 gigabit ethernet
On 4/7/07, Robert Sherwood <[EMAIL PROTECTED]> wrote: Does anyone know whether the PCI or PCI-x backplane even has 10 gbps of throughput? Correct me if my info is wrong :-) IIRC one PCI-Express line equals bi-directional sync. 250 MiB/s. The fastest setting which is available now is AFAIK 32 lines per device. I wouldn't be surprised if those cards use PCI-e 8x slots, which give around 2 GiB/s and are fairly available in high-end machines, your typical PC excluded ;-) as most "standard" boards include one 16x slot or (SLI/CrossFire) 2x "physical" 16x slots, which are wired 1x&16x or 8x&8x depending whether you use SLI or not. On server/workstation boards it's fairly easy to get 8x slots. MacPro, IIRC, can support two cards at 8x, especially if you cut off bandwidth to graphic card (It was advertised to have configurable bandwidth settings, i.e. all slots could accommodate up to 8x or more, but you had less "lines available"+config program in firmware allowing you to set bandidth to each slot.) -- Paul Lasek
Re: [9fans] qemu, kvm, xen
On 4/6/07, ron minnich <[EMAIL PROTECTED]> wrote: [cut] You can also use the current sources from kvm's website (I am currently using kvm-16 w/ add-scsi patch). It's easy to setup unless you have gcc >3.x _and_ 64-bit userland Also, compiling patched qemu with gcc newer than 3.x means you can run only w/ kvm enabled. First problem I hit with kvm was an emulation problem, so you do need to modify your plan9.ini to set *norealmode=1 The far jump in again16bit causes kvm to crash and burn (look for the "EA", etc. at the end of again16bit). I never noticed that - I had troubles with march cd's 9pcf kernel, but using an old one from ca 2005 solved the problem of hangup after "running /bin/rc". On the other hand, I use AMD's SVM instead of intel's VTx, and they do differ in some places, as qemu needs to put most of real mode through emulation. [cut] Unfortunately I haven;t had time to do any benchmarking. The only one I could say I have performed is that after switching to SCSI I have been able to sit through the whole installation process without falling asleep... thanks ron -- Paul Lasek
[9fans] Re: patch for working LSI 53c895a in kvm-16 QEMU
[cut] I have tested the patch for the last few days, should be stable although I haven't checked it under heavy load. Maybe somebody could provide a SCSI BIOS from 53c895a? Maybe it would allow to enable booting from simulated SCSI, at least in unofficial way. Since I only have an Adaptec 7950 I cannot use it's BIOS and I doubt my chances in writing device driver w/ QEMU emulation for it :-) -- Paul Lasek
[9fans] patch for working LSI 53c895a in kvm-16 QEMU
This is a I found some time ago using google, unfortunately I don't remember original author. I had rewritten the patch (original file for some reason was malformed) and changed device id of emulated controller to match the one found in my plan9.iso. However, I only tested (and written it) using modified qemu sources from kvm-16 distribution, so I don't if it works with stock qemu-0.9. The patch is very simple, it only supports hard drives and doesn't have a SCSI BIOS (There's sign for preparing a better one in qemu code), however, it works and i have a functional installation using emulated 2GB scsi hd with floppy boot. The only thing is that 9pcf kernel from somewhere around february stops when starting rc, using an old (ca. 2005?) kernel solved it. 9pccd works flawlessly. I think there was some speedup compared to emulated IDE, however, Plan9 installation in qemu (I don't count my test install on old pc, as it was with old iso) for some reason is still veeeryy slow. I think it's userspace problem, since most of the time there's _no_ disk activity at all during "copydist". Since IO works fine for everything other than installer, I am very confused. I had the same 'slow install' problem every time I had installed Plan9 (That includes pc with i440bx and ATA33 7200rpm drive, netbsd-xen0 with lsi53c895 and 7200 SCSI hd and many tries under both VMWare and Qemu). Now, off to change terminal into cpu server -- Paul Lasek add-scsi Description: Binary data
Re: [9fans] How can I shift a variable other than ?
On 3/13/07, Anthony Sorace <[EMAIL PROTECTED]> wrote: On 3/13/07, C H Forsyth <[EMAIL PROTECTED]> wrote: > anyway, as to the archaic nature of shells. > >i also find it bizarre that you can call rc "old cruft"... > > i supposed that was a reference to the fact that the style of these shells hasn't > changed all that much since 1977. interestingly, the most different shell i've seen is Windows PowerShell (formerly MSH, aka Monad). not to say i'm particularly a fan, but the idea of an OO CLI is interesting. AFAIK isn't it the only "normal" official way of using the whole NT namespace? I always find the fact that NT uses Unix-style files (complete with ioctl :D) for device access but that part of namespace is usually hidden deep inside... Although what they are doing for Linux-based PalmOS replacement can rival it... (It includes completely different system - it has unix kernel but afaik uses many concepts alien to unix as base) -- Paul Lasek
Re: [9fans] interesting potential targets for plan 9 and/or inferno
On 3/7/07, Martin Neubauer <[EMAIL PROTECTED]> wrote: [cut] I actually had problems compiling old drawterm code on my gentoo amd64 box. The error looked similar, yet I found the offending part to be some kind of type mismatch which got loose because on amd64 and x86 the types involved were little different in size. setting CC='gcc32' solved the problem and I've got nice, statically linked drawterm 32bit binary. Which doesn't change the fact that I still cannot get Plan 9 to work on my kvm-qemu. A very old ISO couldn't create windows in rio and the new one freezes during boot from disk. The old one works perfectly except for rio. And as for future roadmap... I rather see plan 9's features incorporated into other OS'es, using libs and specially crafted namespaces to support "legacy" apps. -- Paul Lasek
Re: [9fans] Anyone to try to convert Acme to full UI (w/graphics)
On 10/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > But my dual-1600x1200-LCD laptop hasn't arrived yet. do you mean 1600*1200 built-in LCD, or just support of external monitor of that resolution, like T23 does?? In case you know about 1600 or better internal LCD laptop, i would be pleased to know about the model, thanks, Eurocom (http://www.eurocom.com) Mobile Workstation line has 17.1" 1920x1200 widescreen model, the rest has 1680x1050 widescreen. I don't know how they will work with Plan9 - I could buy a *new* car (and pretty good one...) for a price of fully equipped Eurocom mobile workstation . (However, I'd choose that D900K F-Bomb over Macbook Pro 17" any time - their price is nearly identical in my case...) ++pac. -- Paul Lasek
Re: [9fans] scuzz doesn't like CD-RW?
On 10/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Depending on the drive, you may also need to write multiples of 2048 bytes, padded if necessary. tar writes multiples of 512 bytes, so using dd to pad it might be necessary. Even then, if you write directly to /dev/sdD0/data, you'll need to fixate (close) the disc. Typical drives accept only 2048 bytes/sector (or variations for certain types of recording where you write not only data but also have to supply all that additional data which makes CD a 700 MB instead of full 1 GB :>). IIRC 2048 b/s is standard sector size for data in CD-ROM standard From what I know, drives supporting 512 bytes/sector are mostly (If not only) SCSI (and similar, although I don't think anybody made FiberChannel CD-RW ;-) ) drives. On such drives you can find additional jumper which sets either 512 or 2048 bytes per sector. Example of such drive is Yamaha 16x4x4 Fast SCSI-II CD-RW. AFAIK the only system which requires such setting is VMS, which uses only 512 mode. I'm not sure, but I think that specification doesn't have option for switching sector size on the fly and propably has fixed data structures which break if incompatible modes are selected. I'm not sure what there is to fear about iso 9660 format. It doesn't encrypt your data and files tend to be written contiguously (I'm not sure if that's required by the format or just a good idea to make reading faster), so digging the data out by hand shouldn't be difficult if suddenly all the world's 9660-reading programs stopped working. As long as nobody starts to put important data in subchannels or uses some of the wierder aspects of ISO9660 (Multiple disk filesystems? Is there any program which is capable of making those at all??). Most common, single session CD's have metadata at the beginning, then files. Multi-session add pointer for 'updated descriptor' or something like that which is address of next descriptor in chain (next session). At least I think it should be much easier to decode (as long as it's pure-data track, without any subchannel craziness) than NTFS (which, to my big surprise, was much easier to decode by hand than ext2). -- Paul Lasek
Re: [9fans] Ideas???
On 9/18/06, Harri Haataja <[EMAIL PROTECTED]> wrote: On Sun, Sep 17, 2006 at 04:10:58PM -0400, John Floren wrote: > On 9/17/06, Pawe? Lasek <[EMAIL PROTECTED]> wrote: > >On 9/17/06, tushar mahule <[EMAIL PROTECTED]> wrote: > >* port mplayer?? It's ugly code, but it works, and it works pretty > >fast ;-D > I second the mplayer vote, because it's possibly the best (from a > user's perspective, I don't know what the code is like) media player > I've ever used. However, before mplayer is useful, I think we kinda > need some more sound drivers. Also, is there hardware accelerated video (scaling!) and fullscreen switching? Theoretically it should be possible to port mplayer's vidix using access to graphics card memory with device files (I don't remember exact files, but there was at least one which allowed to even write pci drivers as filesystems if one wanted to...) Integrating it with rio would be much tougher, but I think that at least vesa driver should be pretty easy to port, considering one finds a suitable way to return control to rio (like the need for "reset" on linux vt after using mplayer's -vo vesa). -- Conquering the galaxy is what bacteria with spaceships would do -- knowing no better, having no choice. -- Greg Egan, "Diaspora" (about alien invasion stories) -- Paul Lasek
Re: [9fans] Ideas???
On 9/17/06, tushar mahule <[EMAIL PROTECTED]> wrote: If you need ideas for lower-level stuff... * IEEE1394a/b device driver (OHCI interface first), allowing to write fileservers supporting different kind of devices... * sbp2 client (maybe host?) * IP/Ethernet over 1394 * Adaptec aic78xx driver. * port mplayer?? It's ugly code, but it works, and it works pretty fast ;-D Of non-programming stuff: * Stop using HTML in e-mails. It shows either: lack of good manners, lack of netiquette in your computer education, general stupidity or mistake. I wish for last case, suspect second one. (But please don't start a flamewar on this...). Those nice fonts looks screwed there (and my monitor has blue = 0 always) ;-) -- Paul Lasek
Re: Re: [9fans] alpha port?
On 9/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: As /sys/doc/port.ms says, --- The compiler assumes that the target CPU supports the optional byte and word memory operations (the ``BWX'' extension). If you have an old system, you can generate code without using the extension by passing the loader the .CW -x option. --- That may not be enough though; dhog thought that some of the device drivers might depend upon byte or word accesses. Plus you'd need to check all the assembly language code for BWX operations. I recall that there was some kind of EV56 emulator for EV45, which added BWX and some other operations to running cpu (like FPU emulator). The problem is that it might be hidden behind some proprietary license. If all goes wrong I'll just need to grep them all... And of course details of I/O and memory management vary across Alpha models. Isn't that the reason PAL exists? ;-) Well, I'll look into netbsd/alpha code for AS255 and check relevant parts. IIRC many things were accomplished in netbsd by using OSF PALcode. But first I'll need to get a place to put my normal computer to do any work, so don't expect anything fast :-) -- Paul Lasek
Re: [9fans] alpha port?
On 9/7/06, Bruce Ellis <[EMAIL PROTECTED]> wrote: i think that's right. i had a 164 which dhog used for alpha stuff. Well, the machine I've got is Alphastation 255/233 with latest SRM available for it. 21064A 233MHz and 128-bit 32MB ram should be enough to try porting Plan9 to it? :-) While I don't have very good coding skills, I'll try to adapt existing code to make it boot, then rewrite loader to allow direct booting from disk drive (pka0: 53c810 scsi). I'll try to bring it's 21041 and my 21040 and 21140 network cards to work too. Unfortunately I can't give any estimates for that work (I don't have normal internet access and I need to prepare a working place for my pc - I'm in the middle of painting/laying floor my room...) Any additional info about plan9 on alpha would be appreciated. brucee -- Paul Lasek
Re: [9fans] alpha port?
On 9/5/06, John Floren <[EMAIL PROTECTED]> wrote: Hi I've heard on #plan9 that there is support for some alpha machines; can somebody who uses that tell me how well it works? What models are supported? Is it a pain to get everything up and working? Thanks I second that question. I can't recall now what models were supported, but I am certainly looking for knowledge about alpha support, since I am going to gain an Alphastation 255/233 which I want to use to play with programming., so I could test if it would work with Plan9 (it has standard tulip network interface and SRM Console. I need to check what kind of SCSI controller is in use.) John -- "The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI -- Paul Lasek
Re: Re: [9fans] I suppose if there's no other way to do it (a quote from the tcl web site)
On 8/12/06, ems <[EMAIL PROTECTED]> wrote: On Sat, 2006-08-12 at 08:50 -0700, David Leimbach wrote: Lies. No more than Slashdot/Open Source propaganda. Jon beat Apple by 6 hours to presenting it to the public. Apple had a fully working product by the presitation. Jon Trowbridge only had a preview of his work. Google Desktop was announced soon after. Thats trends for you IIRC Microsoft was talking about this since ca. 1994 They still haven't implemented it fully with part of it's features being available in Vista and indexing (disabled by many people and not that useful anyway) available at least since NT 5.0. WinFS is available as beta at the moment and IIRC Beagle/Spotlight still work better without redesigning filesystem :-) If somebody dug deep enough I think you could find an even older info about this :-D -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
On 7/24/06, Ronald G Minnich wrote: you're probably fine on older linux distros. nexus is netbsd 3.0 xen0 kernel (the one bundled with distro), because we have enough windows and linux machines and wanted a place to have fun with *BSD. NetBSD got in because of having both host and guest kernel, allowing us to dump linux (which was to be the host in the beginning, with *bsd guest and plan9 guest), which is good with our limited resources (128MB ram isn't much when you have to divide it between 3 oses and xen :-) ) ron -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
On 7/24/06, Ronald G Minnich wrote: sure, assume that. What could possibly go wrong? IT's just software! Well - After my last work of trying to get cpu/auth server running I got quite tired with software :-) And when I am tired I start to think about worst cases which software do you mean here? xen 2, xen 3, plan 9 on xen[23]? All of it :-) My original intent was if any bit required to compile xenU kernel has changed enough to break compilation - but I'll try it, as soon as I get back to nexus (proliant machine) console - which will be in September ron -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
On 7/24/06, Ronald G Minnich wrote: once I got it going on 2.0, there was really nothing to do. And now that Richard Miller has it going on 3.0, there is again ... not much else to do. Every time I used 2.0, it Just Plain Worked -- try the Xen-knoppix cd. So I am safe to assume that when I'll try to recompile the sources there won't be some fuc*-up because of version mismatch? :-D Actually it's pretty important information - When I return to school I'll be propably upgrading our plan9 cpu/auth server (the proliant box) while making it work at last :-) (Still can't get auth working so I could drawterm inside...) I can not yet build xen 3.0 on my box, but as soon as I can , well, I'll be doing plan 9 + xen It would be interesting to see Plan9 as Xen3 guest... because I have seen somewhere an "inofficial" linux/xen3 module named along the lines of "nvidia-xen" :-D Since I can;t spare another machine at home, I'd like not to loose hw accel on graphics (And no, it's not because of a lot of pixels for desktop - actually my desktop works fine with low footprint while looking IMHO better than Gnome/XGL :D) ron -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
the installation should have asked you whether you want dma turned on, if you said "yes" and it was still slow then the chipset is probably not supported. with dma on the installation copies all files in less than 5 minutes on reasonable hardware. Back when I have been installing it didn't ask anything about DMA. I'll check if I can spare the bandwith to download newest ISO... when you get to it, run 'pci' and send it to the list. it may turn out that we just need to add the did/vid pair to sdata.c... I don't know about Xen support (it seems that nobody touched it since wiki article), but my chipset (on both machines) is i440bx - rather supported IIRC :) -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
On 7/24/06, andrey mirtchovski <[EMAIL PROTECTED]> wrote: did you try 'echo dma on > /dev/sdC0/ctl; echo rwm on > /dev/sdC0/ctl'? I didn't, because I didn't know about it - It was my first try at Plan 9. Maybe someone with access could add this to install instructions? what does 'cat /dev/sd??/ctl say? Unfortunately I can't answer it now (I don't have time nor free machine to work with). I'll check it next time. Thanks for help. -- Paul Lasek
Re: [9fans] installing Plan 9 under Microsoft's free Virtual PC?
On 7/24/06, elbing <[EMAIL PROTECTED]> wrote: I've got running Plan9 in a Virtual PC 5.3.582.27 (not free), with XP in an Acer Aspire AMD 2.0GHz (Sempron 3000, 1GB RAM) and tipycal hardware. When it asked me about mbr, it offered to create a new mbr, I said "y" and installation continued without problems. It copied filesystem very slow, around one hour. Normal, at least for me - never got Plan 9 to copy itself faster than nosebleed (since I never had time to delve into it, I left it as-is), no matter on what it was installed... tried hardware: Celeron 1100 MHz, 256MB RAM, 5400 4.3GB ata-disk (slow drive, about 10 MB/s peak?) - I stopped checking how much time passed and found myself a long book (after around 1 hour) the same - under Xen 2.0.7, same disk (needed to left it to work at night) the same - under Qemu w/o kqemu, disk image on 7,200 120 GB ata-drive (maybe not a speed demon, but fast drive) (all night work again) Compaq Proliant 1850R (netbsd xen 2.0.7 host), 1x Pentium II 400 MHz, 32 MB ram, installing with disk being an image on UFS at 7,200 SCSI 4,3GB (got plan9 installed after over 2 hrs) Elbing -- Paul Lasek
Re: [9fans] Plan9 installation invading the other partitions?
On 7/24/06, Harri Haataja <[EMAIL PROTECTED]> wrote: I've taken damage on reiserfs and found out that there wasn't really much anything in a way of recovery tools or diagnostics. About everything anything managed to say that the fs is dead. XFS is still the only system that I've had nearly guaranteed data loss (and not much sign of when or where until you find the blank files) if anything goes wrong with a fs in use. Never on Irix, though. There it always worked flawlessly despite equal randomness in power status and hardware faults etc. At the moment (well, that means the last few years; installations aren't that frequent) I'm sticking to ext3 on any Linux hosts I may be looking after. I only wonder since I've _never_ had data loss with XFS while I managed to destroy around 40% of data by shutting down power to ReiserFS :-) -- Paul Lasek
Re: [9fans] Swap considered harmful (Sorry)
On 7/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: it used to be solaris (i don't know if this is still the case) would evict pages to swap even when used + cache << phys memory. i did quite a bit of performance work on solaris, and found i couldn't use more than a fraction of available memory. we moved the same applications to aix and got much better performance with the same amount of physical memory, as we were memory bound. IIRC, the performance increase from swap on linux is in IO code, which used swap as a sort of organized buffer for apps or something like it, while giving more core to apps. Not sure about this, I'd have to check archives for that. It was in a discussion about whether prepare swap when you have such amounts of memory as today :) - erik -- Paul Lasek
Re: [9fans] Swap considered harmful (Sorry)
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: i typically run with 128MB real memory and 750MB of swap *used* (out of 4G). the oom killer hasn't been up on murder charges on my machine yet. The only time I had seen OOM-killer running was when I invoked it directly by SysRq combo. I had once reached full memory and swap, but even then OOM-killer didn't run - I am not sure if 2.6.x line didn't changed the default behaviour, as the only think that happened was gcc complaining "Out of Memory" during compilation of Open Office (never more - I have given up and used binaries and OTOH, for my own works I mostly use TeX) and killing itself. And swap had given me enough to not remove it - and on linux, strangely, even on systems with godlike amounts of memory, small swap was found to be a good choice (Something about caching/mapping and so on). And as for Plan9... when you have at most 40 MB, swap is a good idea :) -- Paul Lasek
Re: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory
On 5/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: isn't wrong to blame shared libraries for this? don't misunderstand --- shared libraries have plenty of drawbacks --- but this seems at first glance to be a problem with the crossproduct of bloated applications and glibc badness? I have a strong feeling that if you kick out glibc and prepare more sensible set of core libraries (keeping all standard-compliant functions + things like RSBAC), most of linux badness would vanish :D and yes, things are getting kludgy. -- Paul Lasek
[9fans] Re: Installing and partitioning for plan9
PC MBR-style partition are _very_ often not sorted. It's the usual situation if you had some repartitioning without changing the whole disk structure (For example, changed only part of the disk) using *nix fdisk - it preserves old partion numbers in order not to screw OS booting (with MBR partition table, it's quite sensible thing to do) But it's not only Plan9's fdisk bug, IIRC Windows 2000 Server did the same to me (Or maybe it was something different), except that it only changed partition numbering to sorted - The only thing I had to was to boot from other medium and change /etc/fstab entries to match new numbers. On 5/5/06, Russ Cox <[EMAIL PROTECTED]> wrote: > Is that the expected behaviour of plan9 fdisk? Not quite the expected behavior, but it's certainly believable. Fdisk assumes that it can pick up the partition table into its internal representation and then rewrite it from that internal representation without breaking anything. It never occurred to me that partitions might not be listed in order (in prep, which fdisk is based on, partition order is irrelevant and therefore always sorted!). I'm also not too surprised about changing the type of extended partition. That shouldn't matter, of course. Changing one of the partition sizes *is* surprising, since I tried very hard not to do that. PC disk partitioning is a giant mess. I've given up. If you think you can fix the bugs without introducing other problems, the source is in /sys/src/cmd/disk/prep/fdisk.c and I'd gladly accept a patch (see patch(1)). Thanks for the report. Russ -- Paul Lasek
[9fans] Re: nvidia scrolling performance
On 5/1/06, erik quanstrom <[EMAIL PROTECTED]> wrote:
PCIe SLI = 2 * 16x = 8G/s, which ought to be enough for just about anyone.
Looks like I have to disrupt some pleasant assumptions
PCI-Express cards don't give a damn about the number of lines that are
connected ("1x" means one pci-express line), the only thing it changes
is the transfer speed.
And except for workstation (traditional sense of specialized mb and so
on) or special gaming motherboards I have yet to hear about a SLI
motherboard with 32 PCI-express lines (Standard PC motherboards
have 20 lines, latest PowerMacs have at least 32 lines - 1*16x 1*8x
2*4x + 4x ones have 8x physical connectors to use 8x cards in 4x mode,
maybe more - need to visit an Apple Store...)
Actually, when you use the switch (hardware or software) to change
into sli mode, you split 8 lines from "normal" port to "second",
making them 2* 8x ports :)
Of course, using special chips (like workstation line of Nforce, hard
to get from what I heard, allows you to build up to *LOT* of lines
:P), you can get the required 32 lines to get both cards working at
2*16x (PCI-Express defines single ports with up to 32x lines)
Of course, each line is 250 MiB/s bi-directional full-duplex (On
PCI-Express, reading from video memory is fast enough, shortly
speaking - it's the core factor for nVidia/ATI low-budget cards like
"Turbo Cache" and so on)
- erik
Over 4 years of trying to buy a new computer - At least I learned a
little from it :D
(Basically all my hardware is n-hand and people ask why it
sometimes it just doesn't work!? Not to mention that it's hard to get
i440bx compatible sdrams these days...)
--
Paul Lasek
Re: Re: [9fans] bootalpha and the no valid stack error
On 4/27/06, Brian L. Stuart <[EMAIL PROTECTED]> wrote: > I've got kind of mixed opinions on the subject of the PALcode. The > multiple console monitors do seem a little pointless. As near as > I can tell, the main motivation behind multiple PALcodes was to ease > porting VMS from the VAX and DigitalUNIX (or whatever it was called > that week) from the MIPS. One had a lot of built-in assumptions about > the VAX MMU and the four VAX processor modes and the other assumed > a lot about MIPS. That naturally led to the usual CS narcotic. "We'll > just abstract it away with an interface layer." In retrospect, it looks > to be an unnecessary bit of complexity. But at least it's vaguely > interesting, > unlike say the 7000 variations of how to specify which block you want > from an IDE drive. If I understand well, PAL code is used to change the behaviour of AXP cpu, much like microcode - Linux PAL code is basically unchanged for all versions of Alpha, different mostly in interrupt handling and such things. Basically it can allow you to compile one plan9 kernel and boot it on every version of Alpha, changing only the bootloader part :) Basically, treat it like a microcode - except that its standard AXP assembly + 5 instructions. Boot process is if I remember: 1. 2. SRM 3. load OS bootloader 4. bootloader setups PAL and all the low level things and prepares environment for OS 5. kernel in control... At least that's how it was supposed to work in MILO (Linux Alpha bootloader) > BLS -- Paul Lasek
Re: [9fans] Google Summer of Code
On 4/18/06, Christopher Nielsen <[EMAIL PROTECTED]> wrote: > On 4/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > My 2Ghz 1Gb RAM workstation struggles to allow me to read email with > > gmail... amazing how far backwards we can go! > > my 700MHz/384Mb thinkpad is quite zippy reading email with gmail. Gmail works more than better with a recent version links, which works perfectly fine even on very old equipment > -- > Christopher Nielsen -- Paul Lasek
Re: [9fans] Writing device drivers
On 4/18/06, erik quanstrom <[EMAIL PROTECTED]> wrote: > thanks for the excellent information. i have the fortune of having a > dac960 controller and an adaptec 7898n in the same machine. lucky me. > a quick look at the dac960 driver for linux doesn't immediately reveal > any firmware. do you think that would be an easier driver to build than > the adaptec? IIRC dac960 has completely OS-independent firmware and communicates using some kind of protocol? with host os - it is only a storage controller with SCSI pass-thru for SCSI Tape. It's not what you'd call a SCSI HBA :) I wouldn't be surprised if dac960 isn't somehow similar to DPT EATA standard, where you didn't give a damn about integrated firmware (DPT Smart* IV controllers used m68k cpu's connected with specialised SCSI co-processor and PCI bus adapter - It's firmware was completely independent (most powerful models had complete 68060 :D) > i don't know a think about scsi bus protocol and i don't have a bus analyzer. > is such a beast affordable? (i am running old va linux boxen after all.) I don't think it's necessary to have a bus analyzer just read SCSI documentation and available source code from *BSD and Linux... > - erik -- Paul Lasek
Re: [9fans] Writing device drivers
On 4/15/06, Anthony Sorace <[EMAIL PROTECTED]> wrote: > personally, i'd love firewire/ieee1394 support, although that's mostly > because i've got a small stack of such disks available to me, mostly > sitting idle. i believe someone (peter bosch?) was working on this a > few years ago. I agree - firewire bus/device class drivers + at least ohci1394 would be a great thing... > for getting familiar with the plan 9 interfaces and such, you can get > started by just writing a driver that does something simple, > software-only. i found that quite educational getting started. go > write /dev/rot13 or something. for something trivial with real > hardware... has anyone ever bothered to write a driver for the PC > speaker? that should be fairly easy (but then, it is a PC, so i > wouldn't be shocked if not). > For a little project - why not create kernel mode port of linux coffee machine driver? (somewhere in the HOWTOs :D) Not so long ago I tried to plunge through SCSI code to make Plan9 work on my machine without Xen&co, but I decided to withdraw when I found I'd have to write a compiler for firmware (and possibly rewrite BSD/Linux firmware) in addition to driver itself... (Adaptec AIC-7892 - UltraWide2...) -- Paul Lasek
Re: [9fans] booting from cd on an intel 440GX dual processor
On 3/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In general, I believe we don't have drivers for RAID cards. They > often turn out to not actually do RAID in hardware (Promise is famous > for this). I think 3ware is an exception and their cards actually do > RAID in hardware. DAC960 is a SCSI disk-only RAID controller, with special protocol for attaching scsi tape drives... it does everything in hw (just like DPT SmartCache/SmartRAID - I have a SmartCache IV, and it contains a 68k processor - different model for different cards, from 680ECxxx on cheapest, to full 68060 on best SmartRAID IV :-) ) -- Paweł Lasek
Re: [9fans] Van Jacobsen's network stack restructure
On 2/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > (BTW, can plan 9 actually use multi-core processors?) > > In principle, yes, since they are just shared-memory multiprocessors > packaged more compactly than previously. > > Having said that, I don't know if Intel and AMD did the obvious thing > and just populated the MP table appropriately or whether they felt > compelled to gratuitously do things differently because the word > `core' is spelled differently than the word `processor', thus > necessitating at least minor kernel changes. Given Intel's past > behaviour, I'm pessimistic. From my knowledge, AMD64 populates ACPI cpu tables with all processors, including every core - the only oddity might be info about where those 'cores' are - Since AMD64 is a NUMA, it should be somewhere :) However, it all depends on BIOS (although those motherboards which boast the sign 'dual-core support' should include it) and what I said complies to 64-bit mode. In 32-bit, it should present standard Intel MP 1.4 tables I think :P -- Paweł Lasek
Re: [9fans] Maybe it is april fool's after all ...
On 1/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Compatibility mode? Why? Surely you just recompile the programme for > the target machine, you have the source, after all. A minute, tops. > > --jim It comes from the fact that some of the code is not-so-portable - OpenOffice 1x being popular example (don't know about 2.0), as it didn't compile on amd64 (some bugs in the code, remember, it comes back from StarDivision and OS/2 :D). There's a lot more of it, thaknfully limited mostly to closed-source software. M$ is having the same trouble, having to supply 386 IE for basically every architecture NT is working on (From what I remember, 386 IE is included in Alpha, IA-64 and AMD64 ones) :) -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei
Re: [9fans] authentication by LDAP?
On 1/3/06, Dan Cross <[EMAIL PROTECTED]> wrote: > The first rule of Hack Club is...You don't talk about Hack Club! Good One ;-) However, we're not aspiring to be any kind of secret organisation ;-P so it's not that useful. And the name isn't mine -- it's literal translation of someone's else idea (nobody thought of anything better... at least we didn't fought over hostnames ^_-) (Although we still didn't started official stuff as we want to bring up Xen with at least linux working + we need to find a place so server could work 24/7) > - Dan C. > > -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.wordpress.com [in polish]
Re: [9fans] authentication by LDAP?
On 1/2/06, Steve Simon <[EMAIL PROTECTED]> wrote: > > One of these flat files could be DNS info from LDAP in ndb(6) format > which you could simply reference in /lib/ndb/local, e.g. [...] > This is all very neat but vapourware at present - sorry, If I do get > around to such a thing I will announce it here. It looks like it will be the first job in our 'Hack club' :D IDEA: On linux machine, every x hours, a cron job will check ldap database for new/changed/deleted entries and translate them to format supported by plan9 software (updating the fileserver's user database in the process). And I decided not to read RFC's nor libldap manual/code... python-ldap or perl-ldap will be used, and since perl-ldap is written entirely in Perl, it might be possible to set it working as native plan9 fileserver (If you call perl program native :) ) The only problem I have is: * Is there a simple way to setup linux box as ndb/auth/fileserver and so on for plan9? * How can I configure some unix DHCP server to send fileserver/auth info to plan9 (I tried with ISC DHCPd... for some reason I can't get it working) * OR set-up Plan9's dhcp server (dhcp info isn't going to change that often as to use LDAP :P ) > -Steve > -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish] http://plasek.wordpress.com [in polish too ;-) ]
[9fans] authentication by LDAP?
Hi. I'm in following situation: We want to have a plan9 machine in school, however, it must share it's users database (usernames, passwords, privs and so on) with NetBSD and Linux. Not only that, we need shared home directories and texmf tree (we don't have much space so why waste it) network is made of 3 virtual machines: nexus: Linux Xen 2.0 host, main server, stores all files devil: NetBSD 3.0/xen-guest usagi: Plan9, xen-guest What I am looking for is a way to hook plan9's databases into LDAP or something similar, so I could change only the global repository. Even better if it would be possible to set the rest, like ndb by it :-) And what about DHCP? For some reason I can't get ISC DHCPD to give valid info about auth servers and so on, would it work to use plan9port and plan9's dhcp server? -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish]
Re: [9fans] PCICIA Modem
On 12/26/05, Martin C. Atkins <[EMAIL PROTECTED]> wrote: > I've got something with (I believe) the same number (and from the same source > - a VAIO). > (I don't have it handy to double check the model number, however) > My modem is a softmodem, and so no, it won't "just" show up as a serial port! > (And I had a good deal of trouble getting it to work under Linux - in fact, > I eventually gave up - the modem worked - eventually, just - but > suspend/resume broke it) Then it's screwed, I say... If it's soft-modem, the only available solution is to write a driver for it. However isn't it rather rare for PCMCIA modems to be soft-modems? At least the one I have is just a "PCMCIA Serial Port", the same goes for the one mounted on Compaq Insight/LightsOut PCI which is in my school's Proliant 1850R. > Martin Good Luck with making it work on Plan9 (At least none of you seem to have the problem of Plan9 not booting at all ;-) ( Solution for me: Run Xen/Linux w/ Plan9 in domain 1 )) -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish] http://plasek.wordpress.com [in polish]
Re: [9fans] MS Research reinvents Inferno?
[snip] > The exact set of examples is not finalized but will at > least include MULTICS, RT-11, 6th edition UNIX, 4.3BSD, VMS, NT/2000/XP > and Xen. Most likely Plan 9 will also appear there. I want to also include > at least one example from the big iron world, but need to find a good > reference for it. Hercules emulator allows you to run virtually any OS for S/390 and descendants, and there are pre-made images somewhere on the Net with turn-key IBM MVS installation. http://www.cray-cyber.org provides public supercomputer systems, from Cray, Control Data Corporation, NEC and Bull :) (guest account is down due to an attack where it was used -_- ) The OS'es there are: Cray: UNICOS(TM) - Unix based CDC 6600-compatibles: NOS or NOS/VE CDC 4680: EP/IX (UNIX based) NEC SX-4: Super-UX - Unix based NEC UP4800: UX4800 11.5 Pity is that only Cray Y-MP EL is 24/7, so you may have to talk with them to have access to others > If we manage to keep to the publisher's schedule and I survive the process, > it should see the light of day in time for fall semester 2007. So if you hear > the murmer of insane babbling coming from the direction of Memphis, > you know what it is. > Brian L. Stuart Keep up with good work, my "Operating Systems Vade Mecum" (R.A.Finkel) is getting a little old :) -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish] http://plasek.wordpress.com [in polish]
Re: [9fans] PCICIA Modem
On 12/9/05, TamTam <[EMAIL PROTECTED]> wrote: > My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I > know... but even better than nothing! ;) > > Is there any possibility to connect with my PCICIA Card Modem? And if yes, > how? Check all possible seiral ports - It should register itself as a standard PCMCIA UART, after all onboard ones. After that you can use it as any other modem connected to serial port. > Thanks for helping, > TamTam > -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish]
Re: [9fans] gmail 0: messages
On 12/9/05, David Leimbach <[EMAIL PROTECTED]> wrote: > > > You tell them that it's for all 9p speaking systems. That includes linux > now with v9fs, hopefully with Alan Cox [FreeBSD Alan Cox], anything that can > use Tim Newsham's Python 9p implementation, etc. :) A fast hack would be to port gmailfs from Linux/FUSE, as it uses not POP, but Gmail WebAPI. As it's already an userspace fs, you would only have to change FUSE-dependant layer and rework it to check "normal" e-mails instead of the ones it uses for file-storage. > It's not as obscure as it once was. I've seen talk of adding it to OpenBSD > as well as a translation layer for DragonFlyBSD's native VFS messaging [well > I proposed that one but god knows when I'll have time for that] I see 9p more as a RPC/resource sharing system - I have a strong feeling that I'd rather use sthg like AFS (if they implement files with size >2GB) or other _fast_ network, file-oriented fs for my files (With driver using 9p as interface :D ) > Anyone interested in adding 9p to NetBSD? :) > > We'll just spread out like a virus and take over. ;-) Why not... just add it to windows, so you could use 9p mount disks... And then I'd only have to write XFS/JFS/UFS2 for 9P and stop caring about not having access to some files :D > Dave -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish]
