Re: [9fans] First/second edition image manipulation tools
On Jun 11, 2008, at 11:46 PM, Russ Cox wrote: The first edition specified the arguments to -o as two values - this cannot be done due to idiosyncrasies with args(2). case 'o': arg1 = EARGF(usage()); arg2 = EARGF(usage()); break; russ According to arg(2), that's not a good idea. "ARGF must be called just once for each option that takes an argument." See if your code works.
Re: [9fans] First/second edition image manipulation tools
> The first edition specified the arguments to -o as two values - this > cannot be done > due to idiosyncrasies with args(2). case 'o': arg1 = EARGF(usage()); arg2 = EARGF(usage()); break; russ
[9fans] First/second edition image manipulation tools
Hello. My next experiment in learning libraries, as well as my next project, is a reimplementation of the first and second edition raster graphics manipulation tools. These use libmemdraw, which provides Memimage. Since I only have a working first edition manual, the program I will present shortly conforms to the first edition. NAME transpose - re-orient an image SYNOPSIS transpose [-vhadrlui] [-o 'x y'] [imgfile] DESCRIPTION transpose produces an image from another image by applying a transformation that satisfies the property of involution. The options are: -d Reflect image through descending axis (y=-x), the default -a Reflect image through ascending axis (y=x) -v Reflect image left-to-right through vertical center line (x=0) -h Reflect image top-to-bottom through horizontal center line (y=0) -r Rotates image right 90 degrees (clockwise) -l Rotates image left 90 degrees (counterclockwise) -u Rotates image upside down (180 degrees) -i Identity (for completeness) If the -o option is given, the new image has the upper-left coordinates given as an argument. Otherwise, the original upper-left coordinates are used. EXAMPLES Mirror image. transpose -v img > img2 Set the origin of an image to (0,0) without changing any pixels. transpose -i -o '0 0' img > img2 Involution exposition. transpose img | transpose > img2 BUGS The first edition specified the arguments to -o as two values - this cannot be done due to idiosyncrasies with args(2). What should I do to supply something like -o outfile? O(N^2) algorithms, even with -i - using -o makes the running time O(2(N^2)). You can find it in /n/sources/contrib/pietro/transpose.c. Pietro
Re: [9fans] upas/fs
On 2008-Jun-11, at 19:31 , erik quanstrom wrote: right. since the date is attached when delivered to a mailbox, why doesn't this date change when it's delivered to a secondary mailbox? why is the assignment a magical property of the inbox? Most likely it's just an artifact of the original UNIX mail implementation. The \n^From separator line got generated at initial delivery time, and the mail client used that as the display time in the message summaries (e.g. Date: not spoken here). Therefore it makes sense to preserve the initial separator line with it's date intact to ensure consistency for display purposes. Think of it as the UNIX ctime of the message. --lyndon
Re: [9fans] upas/fs
>> by the way, does anyone know the rationale for the date on the >> unix "From " line? upas sets it to the date the message is originally >> delivered to the inbox. moving it from the inbox to another folder >> does not change the date. > > the date is the date it was delivered. > it's a receiver-side postmark. > but you knew that. what's your question? right. since the date is attached when delivered to a mailbox, why doesn't this date change when it's delivered to a secondary mailbox? why is the assignment a magical property of the inbox? - erik
Re: [9fans] upas/fs
> by the way, does anyone know the rational for the date on the > unix "From " line? upas sets it to the date the message is originally > delivered to the inbox. moving it from the inbox to another folder > does not change the date. the date is the date it was delivered. it's a receiver-side postmark. but you knew that. what's your question? russ
Re: [9fans] store 9p session-only values using lib9p
> Hello > > I've a 9p server implemented using lib9p which serves decoded files, for > example, i have a base64 encoded file i want to read, but i want to decode it > at the same time the client reads. Then i need to save two offsets, the one > sent to the client corresponds to the decoded data, and i need other which > correspond to the original data. (base64 is an example, rfc2047 codification > is the main issue) > > If i save the offset adjustment in f->aux or simmilar, i can calculate the > real file offset on the next T-reads, but that will only work if one client > reads it at one time. > > could that value be saved for each session? > > i would love to hear from other's experiences, i've been spending a little time with upas/fs. i don't think that in general one can get by parsing part of an email, unless that part happens to be top-level headers. there are more transforms than you've mentioned. apple mail loves to put nulls in html email, for example. traditional mbox format is problematic, too. if you wish to control memory usage (which is a serious problem for upas/fs), i think the way to go is a cache with reference counting. the stuff i have isn't ready for prime time, but it's coming along nicely. by the way, does anyone know the rational for the date on the unix "From " line? upas sets it to the date the message is originally delivered to the inbox. moving it from the inbox to another folder does not change the date. - erik
Re: [9fans] Modularizing plan9port
> Okay, how can I make sure the right toolchain is used, *all* > imports come from within sysroot and *only* code from the > (building) HOST system is executed - *never* from TARGET ? I would have expected your host system to refuse to run binaries for the target architecture. You are clearly doing far more complex things than my simple brain can fathom. Good luck. Russ
Re: [9fans] store 9p session-only values using lib9p
hello you're right, i will think a bit more about it. thank you very much, gabi
Re: [9fans] store 9p session-only values using lib9p
> If i save the offset adjustment in f->aux or simmilar, > i can calculate the real file offset on the next T-reads, > but that will only work if one client reads it at one time. No it won't. Even if just one client is reading, that client might seek. You could assume that most reads will pick up where the last one left off, and use f->aux to point at a single hint that you can check. Maybe you're willing to do more work if you do get a seek. Otherwise you'll need to build a more complex data structure to help you map between the two. Also, if f is a Fid* (not a File*), then you get a different f for each different Topen of the file (and thus also for each client), so the hint-per-Fid usually works pretty well in practice for this kind of thing. Russ
Re: [9fans] Modularizing plan9port
* Russ Cox <[EMAIL PROTECTED]> wrote: > I think you should be able to cross-compile it > pretty easily if you already have a cross-compilation > environment set up. > > 1. Build a local plan9port tree, put it in the chroot > environment, and put it at the end of your chrooted $PATH. Note: sysroot != chroot. (sysroot *only* applies to the toolchain's search pathes) > 2. Edit that tree's 9 script to override $PLAN9 with > the path to the local tree (1 line change). > 3. Extract a fresh tree somewhere else. > 4. run SYSNAME=xxx OBJTYPE=xxx INSTALL in the fresh tree. > (assumes Okay, how can I make sure the right toolchain is used, *all* imports come from within sysroot and *only* code from the (building) HOST system is executed - *never* from TARGET ? > I haven't tried this (I find it much easier just to set up > a dedicated machine of the right OS and architecture > and use its native tools), but having the local copy of No, I can't have one dedicated machine per target right here. And most of my targets aren't even capable of compiling. > That sounds like a lot less work than your original proposal. Even if I could go this way, it would require *much* more manual works. Simply too expensive. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] Modularizing plan9port
On Wed, 2008-06-11 at 14:23 -0400, Russ Cox wrote: > I find it much easier just to set up > a dedicated machine of the right OS and architecture > and use its native tools Speaking of which: am I the only one betraying the true cross-compiling in favor of virtualized copies of the OS/platform? I mean, with Qemu and abundance of images it just seems way easier these days. Thanks, Roman.
[9fans] store 9p session-only values using lib9p
Hello I've a 9p server implemented using lib9p which serves decoded files, for example, i have a base64 encoded file i want to read, but i want to decode it at the same time the client reads. Then i need to save two offsets, the one sent to the client corresponds to the decoded data, and i need other which correspond to the original data. (base64 is an example, rfc2047 codification is the main issue) If i save the offset adjustment in f->aux or simmilar, i can calculate the real file offset on the next T-reads, but that will only work if one client reads it at one time. could that value be saved for each session? i would love to hear from other's experiences, thanks, gabi
Re: [9fans] Modularizing plan9port
On Wed, Jun 11, 2008 at 2:53 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * Uriel <[EMAIL PROTECTED]> wrote: > >> Cross-compiling in Gnu/land is a nightmare not worth going into. > > No, it isn't - as long as you've got a proper toolchain and > get around autoshit. (eg. I've got my own libtool implementation ;-p) > no, it isn't - as long it is.
Re: [9fans] Modularizing plan9port
"I need a way to cross-compile plan9port" would have been a much more productive opening statement than "I'm going to modularize plan9port". I think you should be able to cross-compile it pretty easily if you already have a cross-compilation environment set up. 1. Build a local plan9port tree, put it in the chroot environment, and put it at the end of your chrooted $PATH. 2. Edit that tree's 9 script to override $PLAN9 with the path to the local tree (1 line change). 3. Extract a fresh tree somewhere else. 4. run SYSNAME=xxx OBJTYPE=xxx INSTALL in the fresh tree. (assumes I haven't tried this (I find it much easier just to set up a dedicated machine of the right OS and architecture and use its native tools), but having the local copy of the tools in the path before running INSTALL should make it use those instead of the ones it builds. That sounds like a lot less work than your original proposal. Good luck. Russ
Re: [9fans] Modularizing plan9port
* Uriel <[EMAIL PROTECTED]> wrote: Hi, > If you want to cross-compile why don't you use Plan 9? I'm not using (native) Plan9 - just a few tools from p9p. For my targets I need to integrate them into Gnu'ish platforms. So, an p9p-compile'd app has to run just like any other app, w/o additionally porting. > Cross-compiling in Gnu/land is a nightmare not worth going into. No, it isn't - as long as you've got a proper toolchain and get around autoshit. (eg. I've got my own libtool implementation ;-p) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] Modularizing plan9port
Hello, On Wed, Jun 11, 2008 at 02:40:38PM +0200, Enrico Weigelt wrote: > > [...] > So I intent do write some script which creates Makefile's from > mkfile's and maybe even does some build-time configuration > (sort of ./configure ;-)). That script(s) could be packet along > with some other fundamental p9p build utils, and this package > then would be the very first in depedency chain. Taking cross- > builds into account, this would be an TOOL or HOST dependency, > since it runs on the building host, not the target - an compiler- > less target wouldn't ever need it (it plays in the same liga as > tools like lex, make, autoconf, etc). FWIW, and this has nothing to do with what should or should not be done with plan9port, for this kind of stuff you can give a look at: http://downloads.kergis.com/risk_comp_1.0C.0.1.tar.gz (I'm the author, this is a BSD licence with public domain configuration files. If some people find this usefull and are uncomfortable with the licence, I can put in public domain the whole stuff. R.I.S.K. was for: Reduced Instructions Set toolKit) This is precisely (for POSIX right now) some simple sh(1) scripts, and a set of sh(1) files setting variables to do this. It embeds processing to use several parsers and scanners (lex(1) and yacc(1)) in a same object file (I don't use this anymore, since I have understood that I needed this due to engineering faults...) This is not rocket science. This is simple (and limited and faulty). And this was done to allow not using any autoHell stuff. It has been used to successfully compile (cross-compile too) and distribute under the *BSD, some flavors of Linux (I lost tracks of all the variations), and Mac OSX. The documentation is the commented scripts by themselves. But as others more gifted have spent less time understanding than I spent myself, putting the emphasis on these sort of tools, is like looking to the finger when plan9 shows you the moon. I put now together: consistancy and concision: "hbrw, an hmg to Kn Thmpsn". Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Running plan 9 on a Toshiba laptop
By disk controller I mean the chipset that handles your disk. I believe (I've had problems myself) that many SATA controllers are still buggy/not supported on plan 9. Toshiba Satellite 2800? I don't think you have the same laptop. That 2800 was a "single core" computer. 2800s are a whole series of laptops 2800-500 would be a celeron based one, etc... (I am asuming that is the laptop you are talking about because it is the only toshiba listed on the "previously on plan 9" section) Get the output from lspci on lunix or some other utility on windows or whatever your usual poison is. Suerte. On Wed, Jun 11, 2008 at 11:12 AM, hugo rivera <[EMAIL PROTECTED]> wrote: > There are no error messages at all, it just freezes in the DMA > question, before I answer anything. > My laptop is listed in the wiki as: "worked in previous releases and > may work in the current one". > I have a SATA disk, is that what you mean by disk controller? > > Gracias por tu ayuda > > Hugo > > 2008/6/10 Lorenzo Fernando Bivens de la Fuente <[EMAIL PROTECTED]>: >> Hola! >> >> Any error message? >> What is your disk controller? >> Have you read the wiki? Is it supported? >> >> Does it freeze whether you choose to use DMA or not? >> >> éxito! >> >> >> >> On Tue, Jun 10, 2008 at 3:51 PM, hugo rivera <[EMAIL PROTECTED]> wrote: >>> Hi: >>> I downloaded the plan 9 iso image a couple of days ago. >>> I just burned it and booted in a Toshiba with an intel Core2 Duo, with >>> a sata hard drive. >>> When I just run plan 9, without installing it, everything runs ok, but >>> when I choose the install option, it starts loading and the freezes in >>> the "use dma" question. >>> Any clues? >>> >>> Saludos >>> >>> Hugo >>> >>> >> >
Re: [9fans] Running plan 9 on a Toshiba laptop
There are no error messages at all, it just freezes in the DMA question, before I answer anything. My laptop is listed in the wiki as: "worked in previous releases and may work in the current one". I have a SATA disk, is that what you mean by disk controller? Gracias por tu ayuda Hugo 2008/6/10 Lorenzo Fernando Bivens de la Fuente <[EMAIL PROTECTED]>: > Hola! > > Any error message? > What is your disk controller? > Have you read the wiki? Is it supported? > > Does it freeze whether you choose to use DMA or not? > > éxito! > > > > On Tue, Jun 10, 2008 at 3:51 PM, hugo rivera <[EMAIL PROTECTED]> wrote: >> Hi: >> I downloaded the plan 9 iso image a couple of days ago. >> I just burned it and booted in a Toshiba with an intel Core2 Duo, with >> a sata hard drive. >> When I just run plan 9, without installing it, everything runs ok, but >> when I choose the install option, it starts loading and the freezes in >> the "use dma" question. >> Any clues? >> >> Saludos >> >> Hugo >> >> >
Re: [9fans] Modularizing plan9port
By the way, silly question, but what would it take to have the kencc port accepted as part of p9p? And a port of of plan9's awk (trivial to do)? It would be nice to be able to rely on a decent utf-8 enabled awk when writing scripts for p9p without worrying about what broken awk does this or that *nix have installed. uriel On Wed, Jun 11, 2008 at 5:43 PM, Uriel <[EMAIL PROTECTED]> wrote: > If you want to cross-compile why don't you use Plan 9? or at least the > port of the plan9 compilers to lunix[1], where cross compiling is the > only way to compile. > > Cross-compiling in Gnu/land is a nightmare not worth going into. > > uriel > > [1] http://gsoc.cat-v.org/projects/kencc/ > > On Wed, Jun 11, 2008 at 5:30 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: >> * Russ Cox <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >>> Ask yourself whether you're doing this because it would >>> actually make your life easier or because of some >> >> It *does* make my life easier! >> >> I'm not just using it for personal stuff, but for lots of highly >> customized production systems, where careful maintenance is >> very important. >> >> Disk space is not the issue, but the amount of code to be >> maintained (source and binary). So the target systems *always* >> should only contain exactly what's needed - nothing more. >> >>> pre-conceived notion that software packaging should be complex. >> >> Actually, I want to make it simpler. You probably can't see this >> since you don't know what happens behind the scenes at my site ;-P >> >> One essential constraint is, that everything's built through an >> sysroot'ed cross-toolchain. Right after compile several checks >> run on the output, packages are then trimmed-down (eg. removing >> all build-time stuff) and then it goes to the testing system. >> Only after the whole pipe ran through properly, the binary >> package is committed to the production systems. >> >>> There's no need to fiddle with the build structure: >>> you could still require the whole tree to build things >>> and then just split up the post-build tree. >> >> The current approach already fails with crosscompiling. >> I *can not* use the in-tree built mk for further building >> and I *must* make sure that imports are strictly coming >> from within sysroot. >> >>> Then you don't have to worry about rewriting Makefiles >>> or adding your own configure scripts or other horrors. >>> I certainly won't take any of that back into the main tree. >> >> You shouldn't generally declare this approach as horror, >> just because autoconf is a horrible example. >> >> >> cu >> -- >> -- >> Enrico Weigelt, metux IT service -- http://www.metux.de/ >> >> cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 >> -- >> Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme >> -- >> >> >
Re: [9fans] Modularizing plan9port
If you want to cross-compile why don't you use Plan 9? or at least the port of the plan9 compilers to lunix[1], where cross compiling is the only way to compile. Cross-compiling in Gnu/land is a nightmare not worth going into. uriel [1] http://gsoc.cat-v.org/projects/kencc/ On Wed, Jun 11, 2008 at 5:30 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * Russ Cox <[EMAIL PROTECTED]> wrote: > > Hi, > >> Ask yourself whether you're doing this because it would >> actually make your life easier or because of some > > It *does* make my life easier! > > I'm not just using it for personal stuff, but for lots of highly > customized production systems, where careful maintenance is > very important. > > Disk space is not the issue, but the amount of code to be > maintained (source and binary). So the target systems *always* > should only contain exactly what's needed - nothing more. > >> pre-conceived notion that software packaging should be complex. > > Actually, I want to make it simpler. You probably can't see this > since you don't know what happens behind the scenes at my site ;-P > > One essential constraint is, that everything's built through an > sysroot'ed cross-toolchain. Right after compile several checks > run on the output, packages are then trimmed-down (eg. removing > all build-time stuff) and then it goes to the testing system. > Only after the whole pipe ran through properly, the binary > package is committed to the production systems. > >> There's no need to fiddle with the build structure: >> you could still require the whole tree to build things >> and then just split up the post-build tree. > > The current approach already fails with crosscompiling. > I *can not* use the in-tree built mk for further building > and I *must* make sure that imports are strictly coming > from within sysroot. > >> Then you don't have to worry about rewriting Makefiles >> or adding your own configure scripts or other horrors. >> I certainly won't take any of that back into the main tree. > > You shouldn't generally declare this approach as horror, > just because autoconf is a horrible example. > > > cu > -- > -- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 > -- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > -- > >
Re: [9fans] Modularizing plan9port
* Russ Cox <[EMAIL PROTECTED]> wrote: Hi, > Ask yourself whether you're doing this because it would > actually make your life easier or because of some It *does* make my life easier! I'm not just using it for personal stuff, but for lots of highly customized production systems, where careful maintenance is very important. Disk space is not the issue, but the amount of code to be maintained (source and binary). So the target systems *always* should only contain exactly what's needed - nothing more. > pre-conceived notion that software packaging should be complex. Actually, I want to make it simpler. You probably can't see this since you don't know what happens behind the scenes at my site ;-P One essential constraint is, that everything's built through an sysroot'ed cross-toolchain. Right after compile several checks run on the output, packages are then trimmed-down (eg. removing all build-time stuff) and then it goes to the testing system. Only after the whole pipe ran through properly, the binary package is committed to the production systems. > There's no need to fiddle with the build structure: > you could still require the whole tree to build things > and then just split up the post-build tree. The current approach already fails with crosscompiling. I *can not* use the in-tree built mk for further building and I *must* make sure that imports are strictly coming from within sysroot. > Then you don't have to worry about rewriting Makefiles > or adding your own configure scripts or other horrors. > I certainly won't take any of that back into the main tree. You shouldn't generally declare this approach as horror, just because autoconf is a horrible example. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] v9fs & virtio
On Wed, Jun 11, 2008 at 6:46 AM, Venkatesh Srinivas <[EMAIL PROTECTED]> wrote: > > The v9fs docs mention that it can use virtio as a transport. How does > one get a 9P server running in such a way that it can be connected to > via virtio? > Writing the presentation on this for KVM Forum right now. There are two current variants -- a gateway server which is integrated into lguest (patches have been posted to the lguest mailing list, but I can put it someplace else if folks are interested) -- then you essentially start lguest and feed it an argument specifying where you server lives (-9p 10.0.0.1:567). The KVM variant was done by Anthony Ligouri, and it has a server integrated into qemu. The patched kvm-qemu requires a "-shared " name to start the server. In both cases, you just mount -t 9p nodev /mnt -o trans=virtio Its stable, but preliminary at this point. The main problem being neither implementation is anywhere near optimal. Lucho had an older version of a kvm which had an integrated spfs-based server, but I'm not sure he's ported that forward. I don't believe there's any support in Plan 9 at the moment for the 9p virtio channel, but it shouldn't take someone that much to add it. I'll try putting up something with a bit more more information and the associated patches on my kernel.org web page. -eric
Re: [9fans] Modularizing plan9port
> I'm going to modularize plan9port a bit. > > Ideally, each component (library, app, etc) should become it's > completely own package. I fail to see what is ideal about this. Ask yourself whether you're doing this because it would actually make your life easier or because of some pre-conceived notion that software packaging should be complex. > So I intent do write some script which creates Makefile's from > mkfile's and maybe even does some build-time configuration > (sort of ./configure ;-)). That script(s) could be packet along > with some other fundamental p9p build utils, and this package > then would be the very first in depedency chain. Taking cross- > builds into account, this would be an TOOL or HOST dependency, > since it runs on the building host, not the target - an compiler- > less target wouldn't ever need it (it plays in the same liga as > tools like lex, make, autoconf, etc). > > What do you think about this approach ? I think you are wasting your time. There's no need to fiddle with the build structure: you could still require the whole tree to build things and then just split up the post-build tree. Then you don't have to worry about rewriting Makefiles or adding your own configure scripts or other horrors. I certainly won't take any of that back into the main tree. If you just want to create a package for the Linux du jour, just build the tree and then make it one big package. If that would be too large a package, you could reasonably split it into four: 28/12 font$PLAN9/font 68/27 bin $PLAN9/bin and $PLAN9/lib/lib*.a 20/4src $PLAN9/src 18/6baseeverything else The numbers are MB, uncompressed and compressed. Splitting out bin/lib makes it easy to swap in binaries for a different architecture. Splitting out src (or font) makes those files easy to drop if you need to scrimp on disk space. There's not much point to anything more fine-grained. Russ
Re: [9fans] Modularizing plan9port
On Jun 11, 2008, at 7:40 AM, Enrico Weigelt wrote: I'm going to modularize plan9port a bit. I'd recommend just leaving it as it is--you can easily pull out and use the pieces you want based off of the current build tree. ... What do you think about this approach ? Way to much like GNU based software and thus another reason not to make those modifications.A better approach is to examine the current INSTALL and surrounding documentation to use the pieces of that that are pertinent to the bits you desire. -jas
Re: [9fans] Modularizing plan9port
> So I intent do write some script which creates Makefile's from > mkfile's and maybe even does some build-time configuration > (sort of ./configure ;-)). That script(s) could be packet along > with some other fundamental p9p build utils, and this package > then would be the very first in depedency chain. Taking cross- > builds into account, this would be an TOOL or HOST dependency, > since it runs on the building host, not the target - an compiler- > less target wouldn't ever need it (it plays in the same liga as > tools like lex, make, autoconf, etc). > > What do you think about this approach ? aren't you skipping a step? how to modularize p9p is not an interesting question until one has decided that it worth doing. why is modularizing p9p a good idea? as you point out, the process creates a number of problems without adding any functionality. - erik
Re: [9fans] Laptop advice
> Does anyone have trouble booting new installations of plan9 on > vmware6? I turn off hwaccel, load the os, and after the install > completes and the system reboots it just hangs. I am still using > systems built on Mahmoud's vmware image (for which I am indeed > grateful). Delete the CD drive from the configuration. Plan 9 and VMware disagree on how an empty CD drive should behave. Russ
[9fans] [PATCH] p9p: 9pserve proxy support
Hi folks,
here's a patch against p9p for an "proxy mode" in 9pserve, like Russ
suggested. It just adds an new "-c" option which tells 9pserve to
dial to an address as it's input connection (instead of taking stdio).
This way, 9pserve can eg. be used as a proxy between a unix socket
and TCP, making p9p servers available via TCP.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
Index: src/cmd/9pserve.c
===
--- src/cmd/9pserve.c (revision 707)
+++ src/cmd/9pserve.c (working copy)
@@ -136,7 +136,7 @@
void
usage(void)
{
- fprint(2, "usage: 9pserve [-lnv] [-A aname afid] [-M msize] address\n");
+ fprint(2, "usage: 9pserve [-c pipe] [-lnv] [-A aname afid] [-M msize]
address\n");
fprint(2, "\treads/writes 9P messages on stdin/stdout\n");
threadexitsall("usage");
}
@@ -157,6 +157,19 @@
ARGBEGIN{
default:
usage();
+ case 'c':
+ {
+ char* pipename = EARGF(usage());
+ printf("pipename=\"%s\"\n", pipename);
+
+if((fd = dial(pipename, nil, nil, nil)) < 0)
+ sysfatal("dial %s: %r");
+ dup(fd, 0);
+ dup(fd, 1);
+ if(fd > 1)
+ close(fd);
+ }
+ break;
case 'A':
attached = 1;
xaname = EARGF(usage());
[9fans] Modularizing plan9port
Hi folks, I'm going to modularize plan9port a bit. Ideally, each component (library, app, etc) should become it's completely own package. This gets tricky because of the boostrapping circle (mk requires lots libs, etc). In the current structure this doesnt harm as mk is built directly with these libs' sources - but an splitted tree won't this way. So I intent do write some script which creates Makefile's from mkfile's and maybe even does some build-time configuration (sort of ./configure ;-)). That script(s) could be packet along with some other fundamental p9p build utils, and this package then would be the very first in depedency chain. Taking cross- builds into account, this would be an TOOL or HOST dependency, since it runs on the building host, not the target - an compiler- less target wouldn't ever need it (it plays in the same liga as tools like lex, make, autoconf, etc). What do you think about this approach ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[9fans] v9fs & virtio
Hi, The v9fs docs mention that it can use virtio as a transport. How does one get a 9P server running in such a way that it can be connected to via virtio? Thanks, --vs
Re: [9fans] Laptop advice
I have an LG A1 "Dual Express" notebook that I bought here in Riyadh a few months ago. It also has a PRPD (pseudorandom pointing device) and it has nearly driven me to the point of spazzing out on several occasions. Other than that it is a great litte laptop. Since it has an external USB device I have not loaded plan9 on bare metal, I run it on VMWare workstation 6. Which brings me to a question: Does anyone have trouble booting new installations of plan9 on vmware6? I turn off hwaccel, load the os, and after the install completes and the system reboots it just hangs. I am still using systems built on Mahmoud's vmware image (for which I am indeed grateful). I would very much like to do clean installs on vmware, especially since I am evangelizing plan9 as much as possible here in Saudi and using it to teach my trainees about operating systems. John On Tue, Jun 10, 2008 at 7:01 AM, <[EMAIL PROTECTED]> wrote: >> 3 buttons and a nipple not a touchpad >> >> no Windows key :) > > These are concrete assets. I know at least one other laptop user (I > have an old Compac Presario 900, he has a newer Acer or some such) > that manages to trigger the touchpad without touching it. Very, very > annoying. As for the Windows key, on the limited keyboard real estate > of a laptop, it is a serious waste. > > ++L > > >
