Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 12:52 PM, lu...@proxima.alt.za wrote: Uriel is renowned for demanding tools to be released on principle, without him having any practical need for them. I don't see why uriel having a practical need for them or not is relevant. I see the relevant question as does /anyone/ in the community have a practical need for the tool?. That's really hard to answer when the mere fact that the tool exists is not readily available to the community (how DO we know about the x86-64 kernel? I think everything I've heard about it has been via uriel). He lands up sounding like a peevish, ungrateful child who just wants more sweets even though his hands are already full. But unlike a child looking for sweets, uriel isn't complaining for his own benefit: What could he possibly need with devtrace anyway? Exactly! His desire is not to get the code for himself, but for the code to be available for anyone who does want to use/debug/develop it. Yes, uriel's manner is abrasive, and it gets old listening to him make the same complaints over and over. But it boils down to this: when uriel perceives an inhibitor to plan 9's growth and development, uriel raises his voice (because no one else will!). Maybe he's not always right, and maybe his righteous attitude makes him hard to reason with, but his heart is in the right place. -sqweek, wishing we could all just get along PS. Congrats on the release, John/Ron/Aki!
Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 12:52 PM, lu...@proxima.alt.za wrote: Uriel is renowned for demanding tools to be released on principle, without him having any practical need for them. I don't see why uriel having a practical need for them or not is relevant. Well, let me try to explain it. Uriel is _not_ an elected representative of the community he makes no bone about despising. Everyone on 9fans (and I presume on the IRC channel) is perfectly capable of standing up for themselves and I, no doubt amongst others, take exception to Uriel (mis)representing my views. Also, Uriel is not even a Plan 9 user. How could he possibly evaluate anyone's need for a theoretical piece of software? Or, for that matter, evaluate the risk of releasing it prematurely? As for the alternative question: does /anyone/ in the community have a practical need for the tool?, the answer is self-evident: Ron needed the software and Ron got it, whatever it took him to achieve this. Can you spot the difference? As for those who did not know about it, why would they have a need for it? And why should they be expecting it to be available? Contrary to Uriel's statements, those who have had something to contribute have been able to do so, it is only in the realm of helping Bell Labs that cards have been kept close to Bell Labs' chest and it is known that Bell Labs does not subscribe to the software development bazaar philosophy, so that should come as no surprise. Me, I am grateful that the current release of the Plan 9 kernel is not encumbered with partial changes to allow unknown parties to experiment with a 64-bit kernel. Perhaps if you think about it you will see my side of it. Uriel does not raise his voice, he whines. And he makes it sound like he's whining on everyone's behalf when it isn't even on his own behalf. That makes him a politician in my book and that's quite enough said. ++L
Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 5:47 PM, lu...@proxima.alt.za wrote: Or, for that matter, evaluate the risk of releasing it prematurely? What risk? -sqweek
Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 5:47 PM, lu...@proxima.alt.za wrote: Or, for that matter, evaluate the risk of releasing it prematurely? What risk? Untested and/or incomplete kernel changes? ++L
Re: [9fans] of historical interest (old Unix filesystems using FUSE)
Didn't Plan 9 have a way to mount 6th and 7th edition disk images also? Was that ever released? yep, it exists, though the support is not as extensive that ancientfs. http://www.quintile.net/magic/man2html/4/tapefs -Steve
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
PS: This is a bit of a call for interest in architectures other than the 386, no matter how much Ron tries to discourage it. Hey, why should I not be able to test the BG code at home?! :-) what other architectures? i'm not aware of anything price/performance-competitive with intel with a open architecture and a reasonable lifespan. although we all complain about backward-compatability in pcs, the original floppy/serial/keyboard, etc. code still work. i'd be interested if anyone knows of an alternative architecture that fits this bill. (note cpu!=arch.) - erik
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
So I take it that you cant use plan9 on a DS10L? Back to earth, I suppose :-) I don't know the answer, but I suspect that if no one presents you with a solution, it means you need to do the porting work yourself. You will get assistance, but in my limited experience and knowledge it is hard to do. There's the rub. ++L
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
Forsyth pointed out that there are no mere mortal accessible [powerpc] platforms for experimentation in this direction. certainly the (few) cheap ones that i knew have vanished. there probably are conventional development boards but those are typically too expensive to be helpful. the situation is much better with ARM; the cost is low but the turnover is still fairly high.
Re: [9fans] ape pwd.h not in sync ?
it won't work, so it's better to find that out when
you compile the program rather than waste time compiling
it only to fail when run.---BeginMessage---
Hi All,
the ape/pwd.h has the following
(in short pw_passwd missing, is this something unwanted ?)
struct passwd {
char*pw_name;
uid_t pw_uid;
gid_t pw_gid;
char*pw_dir;
char*pw_shell;
};
Linux has:
struct passwd
{
char *pw_name;/* Username. */
char *pw_passwd; /* Password. */
__uid_t pw_uid; /* User ID. */
__gid_t pw_gid; /* Group ID. */
char *pw_gecos; /* Real name. */
char *pw_dir; /* Home directory. */
char *pw_shell; /* Shell program. */
};
BSD:
struct passwd {
char*pw_name; /* user name */
char*pw_passwd; /* encrypted password */
uid_t pw_uid; /* user uid */
gid_t pw_gid; /* user gid */
time_t pw_change; /* password change time */
char*pw_class; /* user access class */
char*pw_gecos; /* Honeywell login info */
char*pw_dir;/* home directory */
char*pw_shell; /* default shell */
time_t pw_expire; /* account expiration */
};
Cheers,
/Prem---End Message---
Re: [9fans] ape pwd.h not in sync ?
it won't work, so it's better to find that out when you compile the program rather than waste time compiling it only to fail when run. It's an interesting philosophy, but it just bites you in a different spot :-) That said, it's obvious from the way the question was posed that there is no single answer. ++L
Re: [9fans] vac messages
I'm doing some nightly backups in a cron from a linux server with p9p vac. Venti runs on a plan 9 filserver. From what I can unvac afterwards, it seems like it's going fine, however I'm getting these kind of messages in the mail sent by the cron daemon: either vac: vtcachelocal: asked for block #5395928; only 144918656 blocks When did you last update? I fixed a bug that would produce messages like this in http://hg.pdos.csail.mit.edu/hg/plan9/rev/206d0c2fc7b5 on October 26. Russ
[9fans] how to install python?
Hello, please, what's the easiest way to install python on plan9? I found python.tgz under fgb. Is that the right way to go? Thanks Ruda
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
On Wed, Dec 17, 2008 at 8:12 PM, lu...@proxima.alt.za wrote: I can help the DS10L. 1. open window 2. look out, make sure no one is in the areas 3. slide DS10L out window Sure, but how do you keep Plan 9 honest if no one checks portability? The Alpha is dead. It never ran 64-bit anyway. What are you proving running a dead machine in a dead mode? Your time is worth more than that. go with the arm. The problem is that time is short, we have few people, and putting lots of time into a dead machine really helps no one. The ARM is incredibly popular, wider usage than x86 from what I know, and much more interesting. I think an ARM port to modern ARM platform would really be wonderful. ron I must grudgingly concur. I'd love to boot Plan 9 on my old Alphastation, but I'm probably going to keep VMS or maybe try a UNIX. Let's let the system die--and I say that as a fan of old computers. Rather than supporting lots of architectures, I'd rather we had support for more hardware. Instead of fixing the port of alpha, write a couple device drivers; find an x86 itch and scratch it. John
Re: [9fans] vac messages
Right, it seems like the files on that server don't have those fixes. I'll update and check if this reoccurs. Thanks, Mathieu ---BeginMessage--- I'm doing some nightly backups in a cron from a linux server with p9p vac. Venti runs on a plan 9 filserver. From what I can unvac afterwards, it seems like it's going fine, however I'm getting these kind of messages in the mail sent by the cron daemon: either vac: vtcachelocal: asked for block #5395928; only 144918656 blocks When did you last update? I fixed a bug that would produce messages like this in http://hg.pdos.csail.mit.edu/hg/plan9/rev/206d0c2fc7b5 on October 26. Russ ---End Message---
Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 12:47 AM, lu...@proxima.alt.za wrote: Ron needed the software and Ron got it, whatever it took him to achieve this. Can you spot the difference?] It's a bit more than that: I saw a need starting in 2000, with the initial open source release; I gave talks to anyone who would listen in DOE and five years later started to get money. Money is a necessary but not sufficient condition. Without people like Eric and Jim and Charles it would still be all just talk; we are lucky to have those smart people. It also takes a willingness, at times, to risk your job, which at least one person on this project has done over the last 3 years. It's a *LOT* of work to get to where we are now. It's also taken the determination of those at Bell Labs who were unwilling to let it all die. I admire their dedication. And we do have a sword hanging over our heads: we've got to get Plan 9 on the top 500 in 2009 or the DOE aspect of this may all go bust. So you're looking at 9 years (feels like 90!) of pushing on strings with a pretty hard deliverable next year. I do see a gradual uptick on this list of people who are finding ways to contribute, and that's good to see. And I also see a gradual realization in my community that Linux is not the End of History where kernels are concerned. BTW, 9vx is making a lot of new fans. The startup is just breathtaking and people get drawn in. This project might only have happened in DOE, which is a very open agency in these ways. It is unlikely that any other branch of the US Gov't would have funded this work -- certainly DARPA would not have. ron
Re: [9fans] devtrace release time
I'm yet to see anyone demonstrate a disadvantage of doing so. the problems with publishing code is you have to: write the manual document the install process remove all the debug cruft that you where leaving just in case field emails about how it: doesn't Work they way I expected it suicides if I press Alt-J the whole design is fucking braindamaged This takes time and effort, and noone wants to just put the code up in a mess, reputations do matter, and we take prinde in our work, don't we? whats worse is if you publish a tar and then somone fixes a load of stuff but in the meantime you are working and your code gets out of sync so you have to merge by hand. use CVS (or whatever is trendy) I hear you say? Well you have to set that up, and if you have CVS you have to police it, what if people check in broken code. It all takes time and concerntration, which would be better spent on getting on with the code and sorting it out. One of the biggest things we lack is Wifi support (IMHO) and Russ put up his incomplete Centrino driver a few years ago. How much interest has that sparked? Similarly the sshv2 code, though we now have openssh so its less of a problem. Ok, the bottom line for me: I AGREE it would be lovely to have an AMD64 kernel for pure kudos reasons (my OS has 64 bits and yours doesn't), BUT, I completely understand why those working on it don't want to release it until they are ready. -Steve
Re: [9fans] devtrace release time
And we do have a sword hanging over our heads: we've got to get Plan 9 on the top 500 in 2009 or the DOE aspect of this may all go bust. So you're looking at 9 years (feels like 90!) of pushing on strings with a pretty hard deliverable next year. Could you elaborate on the top 500? And why is the community only alerted now to this potentially very clear objective? I'm sure we'd all want to be of help rather than hindrance in such a situation? ++L
Re: [9fans] devtrace release time
On Fri, Dec 19, 2008 at 1:54 AM, Steve Simon st...@quintile.net wrote: I'm yet to see anyone demonstrate a disadvantage of doing so. the problems with publishing code is you have to: write the manual document the install process remove all the debug cruft that you where leaving just in case No no no, this is all release oriented stuff! Just put the code up so if someone really interested happens by they can check it out and work the details out themselves. What's the disadvantage there? field emails about how it: doesn't Work they way I expected it suicides if I press Alt-J the whole design is fucking braindamaged I'm not understanding how feedback qualifies as a disadvantage. Unless you're writing a twitch game or MMORPG, then I could understand not wanting to hear from your users. and we take prinde in our work, don't we? Of course. But it's silly to entertain the notion that code comes off our fingertips perfect and fully formed. It's software: there's bugs, there's design flaws, development is incremental. Often it can be useful long before it is perfected. whats worse is if you publish a tar and then somone fixes a load of stuff but in the meantime you are working and your code gets out of sync so you have to merge by hand. At least this represents a modicum of cooperation. Without the published tar to start from, that someone may well start from scratch and duplicate whatever effort you've already put in. Good luck a) finding and b) merging any fixes from a completely separate tree. use CVS (or whatever is trendy) I hear you say? Well you have to set that up, and if you have CVS you have to police it, what if people check in broken code. It all takes time and concerntration, which would be better spent on getting on with the code and sorting it out. Disagree. Well, you're right that it takes time. But that time is a one time cost, to set up and learn to use the VCS. Once you've made that investment there is no constant drain on your time/concentration. I'm not sure I agree that the time is better spent coding - I think if you actually sat down with a modern DVCS like mercurial or git you'd find it actually creates quite a nice environment for collaboration. No need to worry about policing anything using the pull model. It's not like version control systems have a monopoly on tools you need to invest time in before gaining productivity from them. Awk, acid, acme, spin all require a certain amount of time investment to understand how they work before the become useful tools. One of the biggest things we lack is Wifi support (IMHO) and Russ put up his incomplete Centrino driver a few years ago. How much interest has that sparked? Like I was saying, publishing code doesn't *generate* interest. It just leaves open the possibility of someone using it later. Similarly the sshv2 code, though we now have openssh so its less of a problem. Michiel was looking at this just the other week. (my OS has 64 bits and yours doesn't), What OS doesn't have 64 bits these days, aside from Plan 9? -sqweek
Re: [9fans] Help with device and clone?
The link routines happen very early, before any user code has run. /lib/namespace is processed by user code. So when the links are running, I think it is simply that there is nothing bound to /net. Russ Thank you... I think I see the issue now. I'm also enjoying: 245 /* set up the network so we can talk to the venti server */ 246 /* this is such a crock. */ Yes, yes it is... --dho
Re: [9fans] Help with device and clone?
Thank you... I think I see the issue now. I'm also enjoying: 245 /* set up the network so we can talk to the venti server */ 246 /* this is such a crock. */ Yes, yes it is... --dho we would all love it if you allowed venti to accept a fd instead of a tcp connection. - erik
Re: [9fans] devtrace release time
On Thu Dec 18 13:08:15 EST 2008, sqw...@gmail.com wrote: No no no, this is all release oriented stuff! Just put the code up so if someone really interested happens by they can check it out and work the details out themselves. What's the disadvantage there? i think you have to understand that some people do not approve of hanging their dirty laundry in public. i think one has to afford them this space. Of course. But it's silly to entertain the notion that code comes off our fingertips perfect and fully formed. It's software: there's bugs, there's design flaws, development is incremental. Often it can be useful long before it is perfected. [...] whats worse is if you publish a tar and then somone fixes a load of stuff but in the meantime you are working and your code gets out of sync so you have to merge by hand. [...] At least this represents a modicum of cooperation. Without the i have some experience in this. i've published some plan 9 early. the downside is that you no longer have any control. and thus you can't necessarly get bug fixes published. there is no law that says, if you accept the original, you must accept bug fixes and improvements. so if one cares about the quality of the result, one believes in one's own abilities, publishing a finished thing can make a lot of sense. this isn't what i do, and i pay a price for it. - erik
Re: [9fans] Help with device and clone?
2008/12/18 erik quanstrom quans...@quanstro.net: Thank you... I think I see the issue now. I'm also enjoying: 245 /* set up the network so we can talk to the venti server */ 246 /* this is such a crock. */ Yes, yes it is... --dho we would all love it if you allowed venti to accept a fd instead of a tcp connection. Maybe I will try to after I understand this a bit better, because it's still not working, and I'm introduced with a couple of issues that I'm still not coming around with solutions for -- that set-up is a really huge hack. I guess I knew it was like that. It seems to be a chicken-and-egg type problem, which I don't think it is. I can't really kbind(#I, /net, MAFTER); at the time that I'm calling ethermediumbind -- it's too early for that. At the same time, I can't really move the links and makekprocdev(ipdevtab); to the area in init0() where kbind()s happen. Maybe I'm missing something totally obvious here, but there must be some way for me to call ethermediumbind() and change its namespace view -- but so far nothing's happening when I add: kbind(#Zplan9/, /, MAFTER); +kbind(#I, /net, MAFTER); +kbind(#l0, /net, MAFTER); kbind(#p, /proc, MREPL); in init0. --dho
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
Well, I don´t know if it qualifies as a moderm arm platform, but once I´m done with some usb stuff I´m doing we at lsub plan to port plan 9 to gumstix. On Thu, Dec 18, 2008 at 5:21 PM, ron minnich rminn...@gmail.com wrote: On Wed, Dec 17, 2008 at 8:12 PM, lu...@proxima.alt.za wrote: I can help the DS10L. 1. open window 2. look out, make sure no one is in the areas 3. slide DS10L out window Sure, but how do you keep Plan 9 honest if no one checks portability? The Alpha is dead. It never ran 64-bit anyway. What are you proving running a dead machine in a dead mode? Your time is worth more than that. go with the arm. The problem is that time is short, we have few people, and putting lots of time into a dead machine really helps no one. The ARM is incredibly popular, wider usage than x86 from what I know, and much more interesting. I think an ARM port to modern ARM platform would really be wonderful. ron
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
i think that would be great, too but i can't think of any arm platforms that are competitive. any suggestions? it depends in large part what competitive means, of course. most of the ARM stuff i'm aware of is handheld or embedded, where intel architectures have a really hard time being competitive in terms of heat and space. handheld devices are a bit tricky because they have more churn in parts between models, but there's plenty of interesting ones to pick from. i like nokia's line, and would love to see a port of Plan 9 (or Inferno) to the 770 or N800 (there's an even newer one, but i forget the model off hand and don't own one of those).
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
till there, if you want to try something in software take a look at http://bitmux.org/qemu.html. i talked once to ron about porting to the gumstix as a gsoc project i'd be willing to do. On Thu, Dec 18, 2008 at 7:12 PM, Steve Simon st...@quintile.net wrote: I´m done with some usb stuff I´m doing we at lsub plan to port plan 9 to gumstix. excellent, I will buy one and join in once you chose a device. -Steve
[9fans] inferno runs on n770 and n800/n810 (was: Re: How can I boot plan9 on my Compaq AlphaServer DS10L?)
On Thu, Dec 18, 2008 at 10:21 PM, Anthony Sorace ano...@gmail.com wrote: i like nokia's line, and would love to see a port of Plan 9 (or Inferno) to the 770 or N800 (there's an even newer one, but i forget the model off hand and don't own one of those). Inferno works perfectly on the n770 and probably on the n800, n810 as well. It's not packaged and doesn't have full-screen mode, but it's quite simple to get it running, though i could not find any use for it. The binary is in caerwyn's inferno emulator collection at http://code.google.com/p/inferno-bin/ and you can probably easily build it yoursef from the current distribution.
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
I´m done with some usb stuff I´m doing we at lsub plan to port plan 9 to gumstix. excellent, I will buy one and join in once you chose a device. -Steve
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
I wouldn't usually do this, as I know this isn't e-bay, :) but since access to non-x86 hardware is being discussed... would anyone be interested in an IBM p630 (POWER4+)? -Ben winmail.dat
[9fans] 9pfuse and O_APPEND
I guess this is mainly a question for Russ: I'm using 9pfuse for a
proof-of-concept project here at Sun and it all works quite
well. My goal is to avoid the 9P2000.u route and use 9P2000
semantics as much as possible, yet allow most of the POSIX
FS functionality to simply work.
In order to do that, I have to extend 9pfuse somewhat. In most
cases my code could be considered complimentary to the
core of 9pfuse, but there's one case which seems to be common
enough to warrant some discussion and potential
changes to the core.
The question has to do with O_APPEND flag. POSIX apps
seem to use it quite frequently (most notably bash uses it
for the most basic of redirections ) but 9pfuse doesn't
really have any support for it:
main.c:_fuseopen
/*
* Could translate but not standard 9P:
* O_DIRECT - ODIRECT
* O_NONBLOCK - ONONBLOCK
* O_APPEND - OAPPEND
*/
if(flags){
fprint(2, unexpected open flags %#uo, (uint)in-flags);
replyfuseerrno(m, EACCES);
return;
}
So here's my question: is there any consensus on how to best
emulate it?
So far, I see the following choices for myself:
* follow what v9fs does and emulate it with llseek(...SEEK_END).
Not ideal,
since it doesn't always guarantee POSIX sematics, but way better
than nothing.
* emulate per-FID DMAPPEND by letting the server (which I also
control) accept Qid
modifications on wstat. My understanding is that existing 9P
servers would simply
reply with Rerror and I can then fallback onto llsek, perhaps.
Border-line abuse of
the protocol.
* reserve (unit)-1 offset in writes as an indication to append to
the end of the file. Really
seems like an abuse of the protocol :-(
There's also a way for me to handle the situation the way I intend to
handle the
rest of POSIX goo: have a dedicated tree with a special aname. But in
case
of a so common operation it seems to be a bit of an overkill.
Thus, I'd really love to hear suggestions that might help integrate
that bit of code back into
the 9pfuse proper.
Thanks,
Roman.
Re: [9fans] 9pfuse and O_APPEND
I would just seek to the end. That's fine unless you have multiple programs writing O_APPEND simultaneously, in which case you are asking for trouble. Russ
Re: [9fans] devtrace release time
On Thu, Dec 18, 2008 at 2:50 PM, sqweek sqw...@gmail.com wrote: You're not in much of a position to mock if you download code marked proof of concept expecting it to be production ready... You must not read this list as much as I thought :-) ron
Re: [9fans] 9pfuse and O_APPEND
On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox r...@swtch.com wrote: I would just seek to the end. That's fine unless you have multiple programs writing O_APPEND simultaneously, in which case you are asking for trouble. yep. The code in nfs clients to support O_APPEND is a wonder to behold. A nicer combination of rubber bands and paper clips you never did see. ron
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
I wouldn't usually do this, as I know this isn't e-bay, :) but since access to non-x86 hardware is being discussed... would anyone be interested in an IBM p630 (POWER4+)? -Ben Only if I don't have to port Plan 9 to it ;) it's got x86 post codes on the front panel! - erik
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
On Thu, Dec 18, 2008 at 4:22 PM, erik quanstrom quans...@coraid.com wrote: it's got x86 post codes on the front panel! but 3 digits right? 50% more POST! ron
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
On Thu Dec 18 19:43:11 EST 2008, rminn...@gmail.com wrote: On Thu, Dec 18, 2008 at 4:22 PM, erik quanstrom quans...@coraid.com wrote: it's got x86 post codes on the front panel! but 3 digits right? 50% more POST! i never saw one with three digits, but i think a third digit would give you 1600% more post! woo hoo. - erik
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
I wouldn't usually do this, as I know this isn't e-bay, :) but since access to non-x86 hardware is being discussed... seeing that gumstix has been mentioned... sitting on my desk is an assembled gumstix (no chassis) that had been intended to be my wearable plan9 terminal. my idea was to run several full framebuffers that could be panned on the touchscreen and displayed on the touchscreen itself or some other screen on the network. Maybe switching framebuffers by tapping, and wearing the keyboard on the body. i haven't touched it. Perhaps somebody here can make use of it before I get around to doing this: 1 x gumstix verdex XL6P (GS270-XL6P) 1 x consoleLCD16-vx (PKG10016) 1 x netCF-vx (PKG10035) 1 x Samsung™ 4.3 LCD panel (LTE430WQF0) (plus various cables and ac power unit for testing) nkl
Re: [9fans] How can I boot plan9 on my Compaq AlphaServer DS10L?
I wouldn't usually do this, as I know this isn't e-bay, :) but since access to non-x86 hardware is being discussed... seeing that gumstix has been mentioned... sitting on my desk is an assembled gumstix (no chassis) that had been intended to be my wearable plan9 terminal. my idea was to run several full framebuffers that could be panned on the touchscreen and displayed on the touchscreen itself or some other screen on the network. Maybe switching framebuffers by tapping, and wearing the keyboard on the body. i haven't touched it. Perhaps somebody here can make use of it before I get around to doing this: 1 x gumstix verdex XL6P (GS270-XL6P) 1 x consoleLCD16-vx (PKG10016) 1 x netCF-vx (PKG10035) 1 x Samsung™ 4.3 LCD panel (LTE430WQF0) (plus various cables and ac power unit for testing) nkl That sounds awesome, and a lot like something I've wanted to make for a long time... just never put up the to get the hardware :) Hopefully you or somebody can make it a reality, because I'd love a wearable Plan 9 terminal. John
Re: [9fans] 9pfuse and O_APPEND
On Dec 18, 2008, at 3:57 PM, Russ Cox wrote:
I would just seek to the end.
Got it. In that case, is there any reason the current version
of 9pfuse doesn't just skip O_APPEND (like it does with
O_LARGEFILE, etc.)? Since 9pfuse revalidate i_size
before writes that's the best one can do anyway(*)
The following patch seems to work for me. If there's
any reason for it NOT to be included in the Hg repo
please let me know:
--- main.c 2008-12-18 18:41:19.0 -0800
+++ src/cmd/9pfuse/main.c 2008-12-18 18:03:27.0 -0800
@@ -576,7 +576,7 @@
flags = in-flags;
openmode = flags3;
flags = ~3;
- flags = ~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC);
+ flags = ~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_APPEND);
if(flags O_TRUNC){
openmode |= OTRUNC;
flags = ~O_TRUNC;
That's fine unless you have multiple
programs writing O_APPEND simultaneously,
in which case you are asking for trouble.
Agreed. Now, here's a bit that I still don't quite
understand: Plan9 does have DMAPPEND on
a per-Qid basis. Why was it decided not to
have it on a per-Fid basis (which would match
POSIX semantics 100%)?
The way I understand -- DMAPPEND is just a hint
to the server to *alway* ignore the offset in
incoming writes. It seems that ignoring offsets
in writes for the Fids that asked for it wouldn't be
much more difficult, would it?
Thanks,
Roman.
(*) After some close examination of the 2.6.27 kernel I actually
wonder why v9fs guys
do an explicit seek in there open.
P.S. Its not different clients I'm worried about. Its something
like this within a single broken client:
int fd = open(/tmp/test.txt, O_RDWR|O_APPEND);
write(fd, 12345, 5);
lseek(fd, 1, 0);
write(fd, 0, 5);
Re: [9fans] 9pfuse and O_APPEND
On Dec 18, 2008, at 4:03 PM, ron minnich wrote: On Thu, Dec 18, 2008 at 3:57 PM, Russ Cox r...@swtch.com wrote: I would just seek to the end. That's fine unless you have multiple programs writing O_APPEND simultaneously, in which case you are asking for trouble. yep. The code in nfs clients to support O_APPEND is a wonder to behold. A nicer combination of rubber bands and paper clips you never did see. Its fun, yes. But I believe this is more of a testament to the statelessness of the NFS plus the fact that the end of file is not a well defined offset (unlike beginning of the file). Thanks, Roman.
