Re: [9fans] sad commentary
Not sure when Mr. Adams wrote this, but I think it was mid-90's. First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII -- and we thought it was a typewriter. Then we discovered graphics, and we thought it was a television. With the World Wide Web, we've realized it's a brochure. Douglas Adams I do have to wonder about the whole TV on your mobile craze. Apparently, there's now features made specifically for the xx-small screen. Does anyone on this list actually watch stuff on those dinky screens? My eyes (and maybe imagination) are not good enough to enjoy that. Robby
Re: [9fans] pull in 9vx
On 7/3/08, Russ Cox [EMAIL PROTECTED] wrote: Yeah, i know i can extract it if I try hard enaugh. Others won't even try. I hope this gets fixed. This just isn't high priority for me. Once 9vx is ready for prime time and there's a real distribution to make, I'll worry about it then. Also, you're really not trying very hard. If the GNU tar is broken (and it appears to be), you can always use the bsd tar (apt-get install bsdtar) or the Plan 9 tar (9 tar). Russ ahhh so this is probably the same reason why the ape libs are empty. -- http://www.fernski.com
Re: [9fans] naive 9vx/fossil question
On Wed, Jul 02, 2008 at 07:12:56PM -0400, erik quanstrom wrote: Native plan9 still booting fine, and here's the configuration for /dev/sdE0/fossil if it's of any relevance: fsys main config /dev/sdE0/fossil fsys main open -V -c 3000 Also, so far only /dev/sda was rw for disk group so I've set /dev/sda1 (which is the whole plan9 partition) to rw as well for disk group, to no avail. almost sounds like an offset problem. do the partition definitions (cat /dev/sd??/ctl) differ between plan 9 native and 9vx? aha, thanks Erik; those definitions indeed differ: from plan9: inquiry HITACHI HTS541616J9SA00 model HITACHI HTS541616J9SA00 serial SB2441GB2441GJJG4K3E firmSB4IC7UP smart disabled flagllba smart power nop reg task 50 cmd c017 serr 0 ci 0 is 0; sig 101 sstatus 0113 geometry 312581808 512 part data 0 312581808 part plan9 63 136760400 part 9fat 63 204863 part nvram 204863 204864 part fossil 204864 135711824 part swap 135711824 136760400 part linux 136760400 138756240 part linux1 138756240 148523760 part linux2 148523823 287189280 part linux3 287189343 291090240 part linux4 291090303 310625280 part linux5 310625343 312575760 from 9vx: loop rw #Z/dev/sda part plan9 63 136760400 part linux 136760400 138756240 part linux1 138756240 148523760 part linux2 148523823 287189280 part linux3 287189343 291090240 part linux4 291090303 310625280 part linux5 310625343 312575760 part 9fat 0 204800 part nvram 204800 204801 part fossil 204801 135711761 part swap 135711761 136760337 The global plan9 one (sda1) seem to be the same in both cases, as well as the other sda* ones (linux), but the subpartitions (not sure they're called that way) inside differ. I suppose the correct one is the plan9 one, i.e 9fat should start at the beginning of the plan9 one (at 63), and not at 0, right? Hence the reason why everything has an offset of 63 inside the plan9 part, I guess. So, what should I do? Is it a bug in 9vx, or is it something wrong in my partitions that I have to correct? Mathieu.
Re: [9fans] pull in 9vx
On Thu, Jul 03, 2008 at 12:00:02AM -0400, Russ Cox wrote: Yeah, i know i can extract it if I try hard enaugh. Others won't even try. I hope this gets fixed. Besides, I guess others will simply try the simple and dummy workaround, as I did, which is to do it as root/with sudo. You'll still get the extended header keyword message, which doesn't seem that bad, but the unpacking will work, as far as I can tell. Mathieu.
Re: [9fans] sad commentary
I do have to wonder about the whole TV on your mobile craze. I share your scepticism however employer doesn't, I find mob-TV meetings are an excellent forum for bullshit bingo. -Steve
Re: [9fans] naive 9vx/fossil question
The global plan9 one (sda1) seem to be the same in both cases, as well as the other sda* ones (linux), but the subpartitions (not sure they're called that way) inside differ. I suppose the correct one is the plan9 one, i.e 9fat should start at the beginning of the plan9 one (at 63), and not at 0, right? Hence the reason why everything has an offset of 63 inside the plan9 part, I guess. So, what should I do? Is it a bug in 9vx, or is it something wrong in my partitions that I have to correct? Notice that you've lost your data partition and you don't have a geometry line. That suggests you are running 0.12, which does not contain Erik's bug fix. If you rebuild 9vx from hg I think things will work better. Russ
Re: [9fans] sad commentary
Quote from a comedian (Rhod Gilbert. maybe?): Well... No. I've got a TV, OK? I'm not interested in watching TV on my phone for the same reason that I'm not interested in having a piss in my tumble dryer.
Re: [9fans] pull in 9vx
Besides, I guess others will simply try the simple and dummy workaround, as I did, which is to do it as root/with sudo. You'll still get the extended header keyword message, which doesn't seem that bad, but the unpacking will work, as far as I can tell. Mathieu. some hospitality at this point would be good for not frightening off these people searching for sanity...
Re: [9fans] Bits of Plan 9 I wish were more popular...
The only issue is that I can't justify the time needed to write Plan 9 drivers when a usable system already exists. Still you could use 9vx to run plan9 on top of this system, that way you could maybe migrate the system gradually. Unless vx32 can run real-time tasks (pretty sure it cannot) that's not much use. Almost every bit of my code (all except a very thin command interface) is living in a loadable kernel module Don't you want Kalman filters in *your* OS kernel? it seems suprising that it all runs in the kernel. doesn't linux support real-time user processes? - erik
[9fans] 9vx.OSX bug: resize on second display causes window to go wrong
I have a 10.5 MacBook with an external display attached. When I start 9vx, things look normal. I can resize the window on the main display. If I move it to the second display and resize, the window goes from good to bad: http://strand1.com/who/anthony/bug/good.png http://strand1.com/who/anthony/bug/bad.png Resizing the window back to the original geometry makes the window good again. Note that this is just a display issue. Things within 9vx continue to run just fine, and can update the display (although that becomes unreliable, especially in the portion of rio windows to the left of where they should be). Dragging my mouse over where the rio window border should be causes the cursor to turn into the resize cursor, and resizing works fine, dragging the still-slanted window around. This happens independent of what's running within 9vx: I see the same thing even with no rio. Anthony
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
I think the problem comes from 9vx picking up the main display's
dimensions as the preallocation for full screen. Drawterm has a fix
for that which loops through all the currently attached displays and
picks up the one with the largest size to decide what the maximum
dimensions should be.
here's the relevant code from drawterm:
/* figure out which display is the largest and return its bounds so we can
* preallocate drawterm's screen to that
*/
Point
get_largest_screen()
{
CGDirectDisplayID *displaylist;
CGDisplayCount displaycount;
OSErr err;
int i;
Point max = Pt(0, 0);
Point curr;
err = CGGetActiveDisplayList(0, NULL, displaycount);
if(err != noErr)
sysfatal(can not enumerate active displays);
displaylist = (CGDirectDisplayID *)malloc(displaycount *
sizeof(CGDirectDisplayID));
if(displaylist == NULL)
sysfatal(can not allocate memory for display list);
err = CGGetActiveDisplayList(displaycount, displaylist, displaycount);
if(err != noErr)
sysfatal(can not obtain active display list);
for(i = 0; i displaycount; i++) {
curr.x = CGDisplayPixelsWide(displaylist[i]);
curr.y = CGDisplayPixelsHigh(displaylist[i]);
if(max.x curr.x)
max.x = curr.x;
if(max.y curr.y)
max.y = curr.y;
}
free(displaylist);
return max;
}
you will need to modify _screeninit() in 9vx/osx/screen.c to something like:
Point max = get_largest_screen();
osx.fullscreenr = Rect(0, 0, max.size.width, max.size.height);
this is tentative. i have no second screen to test right now.
On Thu, Jul 3, 2008 at 8:38 AM, Anthony Sorace [EMAIL PROTECTED] wrote:
I have a 10.5 MacBook with an external display attached. When I start
9vx, things look normal. I can resize the window on the main display.
If I move it to the second display and resize, the window goes from
good to bad:
http://strand1.com/who/anthony/bug/good.png
http://strand1.com/who/anthony/bug/bad.png
Resizing the window back to the original geometry makes the window good
again.
Note that this is just a display issue. Things within 9vx continue
to run just fine, and can update the display (although that becomes
unreliable, especially in the portion of rio windows to the left of
where they should be). Dragging my mouse over where the rio window
border should be causes the cursor to turn into the resize cursor,
and resizing works fine, dragging the still-slanted window around.
This happens independent of what's running within 9vx: I see the same
thing even with no rio.
Anthony
Re: [9fans] naive 9vx/fossil question
On Thu, Jul 03, 2008 at 07:06:59AM -0400, Russ Cox wrote: The global plan9 one (sda1) seem to be the same in both cases, as well as the other sda* ones (linux), but the subpartitions (not sure they're called that way) inside differ. I suppose the correct one is the plan9 one, i.e 9fat should start at the beginning of the plan9 one (at 63), and not at 0, right? Hence the reason why everything has an offset of 63 inside the plan9 part, I guess. So, what should I do? Is it a bug in 9vx, or is it something wrong in my partitions that I have to correct? Notice that you've lost your data partition and you don't have a geometry line. That suggests you are running 0.12, which does not contain Erik's bug fix. If you rebuild 9vx from hg I think things will work better. Indeed, works like a charm with the build from hg. Thanks. Mathieu.
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
Is there any way we could solve the current state of affairs if that's the royal we you're using then sure, there is a way: simply download the latest versions of all programs that you're interested in unifying (p9p, drawterm, 9vx, acme-sac, inferno), merge the osx drawing code (using the best solution available, which for some things is 9vx, for others acme-sac, for thirds yet, p9p), redistribute the new code to the respective maintainers and then track each new release of the code (or periodically check) for changes to redistribute. the only reason you're not in the same mess with the X11 code is that the base everyone cloned was mature.
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
X11 code is still broken in various places, for example in Inferno-os (and even more so acme-sac, which is missing some of the updates that made it into inferno-os). So my comment applies as much to the osx code as to the x11 code, and to hypothetical win32 code. That is the whole point, that every time there is a new port, the same dance starts over again, and even when code is 'mature' its maintenance in some systems (eg., p9p) is better than others (eg., inferno-os). If there was a single codebase shared across projects none of this would be an issue at all. uriel On Thu, Jul 3, 2008 at 5:30 PM, andrey mirtchovski [EMAIL PROTECTED] wrote: Is there any way we could solve the current state of affairs if that's the royal we you're using then sure, there is a way : simply download the latest versions of all programs that you're interested in unifying (p9p, drawterm, 9vx, acme-sac, inferno), merge the osx drawing code (using the best solution available, which for some things is 9vx, for others acme-sac, for thirds yet, p9p), redistribute the new code to the respective maintainers and then track each new release of the code (or periodically check) for changes to redistribute. the only reason you're not in the same mess with the X11 code is that the base everyone cloned was mature.
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
On Thu, Jul 3, 2008 at 8:55 AM, Uriel [EMAIL PROTECTED] wrote: If there was a single codebase shared across projects none of this would be an issue at all. you are right but it's a hard problem, we're all tight for time, so the only fix is for somebody to step up and do it. But your question, 'wouldn't it be better to have one thing to do all this different stuff', is certainly answered probably. ron
Re: [9fans] 9vx.OSX bug: resize on second display causes window to
But your question, 'wouldn't it be better to have one thing to do all this different stuff', is certainly answered probably. you mean like a fileserver? - erik
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
Greetings,
Thanks for finding that snippet, andrey :-) I was about to search the
acme-sac code for it so I could post a patch.
After looking through the 9vx code, it looks like russ is handling
memory allocation for the screen a little differently
than acme-sac (and possibly drawterm).
In acme-sac, I:
* calculate the maximum possible screen size using the function andrey posted
* allocate a giant block of memory to handle this size once in screeninit()
In 9vx it looks like russ is:
* calculating the new window size on resize event
* dynamically reallocating the necessary memory for each resize
Perhaps this has something to do with andrey's problems?
--underspecified
P.S. 9vx will only go into fullscreen on the main display.
The follow fix should work, but I can't test it now, as I am without
an external monitor.
diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c Fri Jul 04 01:20:59 2008 +0900
@@ -513,7 +511,9 @@
}else{
HideWindow(osx.window);
oldwindow = osx.window;
- BeginFullScreen(restore, 0, 0, 0, osx.window, 0, 0);
+ GDHandle device;
+ GetWindowGreatestAreaDevice(osx.window,
kWindowTitleBarRgn, device, NULL);
+ BeginFullScreen(fullScreenRestore, device, 0, 0,
osx.window, 0, 0);
osx.isfullscreen = 1;
osx.fullscreentime = msec();
On Fri, Jul 4, 2008 at 1:05 AM, ron minnich [EMAIL PROTECTED] wrote:
On Thu, Jul 3, 2008 at 8:55 AM, Uriel [EMAIL PROTECTED] wrote:
If there was a single codebase shared
across projects none of this would be an issue at all.
you are right but it's a hard problem, we're all tight for time, so
the only fix is for somebody to step up and do it.
But your question, 'wouldn't it be better to have one thing to do all
this different stuff', is certainly answered probably.
ron
Re: [9fans] Bits of Plan 9 I wish were more popular...
On Thu, Jul 03, 2008 at 08:51:22AM -0400, erik quanstrom wrote: The only issue is that I can't justify the time needed to write Plan 9 drivers when a usable system already exists. Still you could use 9vx to run plan9 on top of this system, that way you could maybe migrate the system gradually. Unless vx32 can run real-time tasks (pretty sure it cannot) that's not much use. Almost every bit of my code (all except a very thin command interface) is living in a loadable kernel module Don't you want Kalman filters in *your* OS kernel? it seems suprising that it all runs in the kernel. doesn't linux support real-time user processes? It all depends on how strict your interpretation of real-time is. The situation with Linux is similar to what I recall existed in SVR4, There is 'real-time domain' scheduling, the POSIX.4 API for finer timing control, and you can lock processes in core to prevent them from swapping/paging... its ok if there is a bit of buffering to smooth out the occasional delay, such as for multimedia applications, but if delayed response to an interrupt could cause your reactor to go critical then it probably isn't good enough. Unix just wasn't designed for hard real-time. The standard solution used in LinuxRT and RTAI is essentially to run Linux on top of a real-time kernel. Your real-time applications then run in real-time on the same machine as your Linux apps with some limited ability to comunicate with them, but don't have access to Linux system calls or libraries. Putting your time critical code into the kernel is another way to get more predictable response times - particularly if you can do the time critical stuff in an interrupt service routine. but again you forgo the normal Linux/User API and library access, and you have to be careful of drivers and other parts of the kernel which may be masking interrupts. It is a bit like the attempts to retrofit multi-tasking to DOS. You are better off designing somethign that has real-time in mind from the start and then retrofitting the Unix/Linux compatability. Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
Sorry, I was a bit hasty with the patch. This one should compile properly:
diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c Fri Jul 04 01:31:37 2008 +0900
@@ -513,7 +511,9 @@
}else{
HideWindow(osx.window);
oldwindow = osx.window;
- BeginFullScreen(restore, 0, 0, 0, osx.window, 0, 0);
+ GDHandle device;
+ GetWindowGreatestAreaDevice(osx.window, kWindowTitleBarRgn,
device, NULL);
+ BeginFullScreen(restore, device, 0, 0, osx.window, 0, 0);
osx.isfullscreen = 1;
osx.fullscreentime = msec();
}
--underspecified
On Fri, Jul 4, 2008 at 1:25 AM, underspecified [EMAIL PROTECTED] wrote:
Greetings,
Thanks for finding that snippet, andrey :-) I was about to search the
acme-sac code for it so I could post a patch.
After looking through the 9vx code, it looks like russ is handling
memory allocation for the screen a little differently
than acme-sac (and possibly drawterm).
In acme-sac, I:
* calculate the maximum possible screen size using the function andrey posted
* allocate a giant block of memory to handle this size once in screeninit()
In 9vx it looks like russ is:
* calculating the new window size on resize event
* dynamically reallocating the necessary memory for each resize
Perhaps this has something to do with andrey's problems?
--underspecified
P.S. 9vx will only go into fullscreen on the main display.
The follow fix should work, but I can't test it now, as I am without
an external monitor.
diff -r ca5b26cbe43a src/9vx/osx/screen.c
--- a/src/9vx/osx/screen.c Tue Jul 01 17:27:41 2008 -0400
+++ b/src/9vx/osx/screen.c Fri Jul 04 01:20:59 2008 +0900
@@ -513,7 +511,9 @@
}else{
HideWindow(osx.window);
oldwindow = osx.window;
- BeginFullScreen(restore, 0, 0, 0, osx.window, 0, 0);
+ GDHandle device;
+ GetWindowGreatestAreaDevice(osx.window,
kWindowTitleBarRgn, device, NULL);
+ BeginFullScreen(fullScreenRestore, device, 0, 0,
osx.window, 0, 0);
osx.isfullscreen = 1;
osx.fullscreentime = msec();
On Fri, Jul 4, 2008 at 1:05 AM, ron minnich [EMAIL PROTECTED] wrote:
On Thu, Jul 3, 2008 at 8:55 AM, Uriel [EMAIL PROTECTED] wrote:
If there was a single codebase shared
across projects none of this would be an issue at all.
you are right but it's a hard problem, we're all tight for time, so
the only fix is for somebody to step up and do it.
But your question, 'wouldn't it be better to have one thing to do all
this different stuff', is certainly answered probably.
ron
[9fans] lguest fixed
I got annoyed with the idea of lguest being broken, I was stuck on a long flight, so I redid l.s and fixed it. The new l.s has the improvements from sources, mainly the 8M pte map instead of the earlier 4M pte map. it's also seriously cleaned up to take into account the new lguest improvements (dare I say churn?) which are, after all, a good thing, since you now start in low memory and can set up the high memory page tables correctly for the MACH structure. OK, could some of you with the loopback 9vx device time something for me? on 9vx, I have a venti and fossil in the file system. hence: index main isect /usr/rminnich/disks/index arenas /usr/rminnich/disks/arenas bloom /usr/rminnich/disks/bloom httpaddr tcp!*!8008 mem 10M bcmem 20M icmem 30M fsys main config /usr/rminnich/disks/fossil fsys main open -AWP fsys main create /active/adm adm sys d775 create /active/adm/users adm sys 664 users -w srv -p fscons srv fossil mk clean is 3 minutes on 9vx, 20 seconds on lguest. mk 'CONF=pccpuf' is 7 minutes on 9vx, 2:40 on lguest Of course, xen on a slower box beats them all, at 12 seconds, so it's not like I'm saying lguest is fast. I need to try kvm next. But I'd be curious to see times on the 9vx /dev/sd. I will be surprised if it makes a huge difference but I'm often surprised. Thanks ron
Re: [9fans] 9vx.OSX bug: resize on second display causes window to go wrong
Is there any way we could solve the current state of affairs with slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac and inferno-os? Each seems to have a set of bugs that somewhat overlaps with the other projects, and they have to be rediscovered, and the fixes moved around again and again. That also would mean that new ports, to for example win32, would propagate much more easily (or at least as far as the gui code is concerned). Every time I edit any of this code I think the same thing, as I'm sure do the maintainers of the other copies, but as the environments are all unpleasant and subtly different, it always seems better to get in and get out quickly than to linger pondering an interface that would satisfy all the involved parties. Are you just whining or actually stepping forward to do something about it? Russ
[9fans] look and feel for iwp9
noble goal: look like plan 9 docs ways to goal: 1. troff 2. tex with the right macros 3. lyx with the right layouts so I have this paper written in lyx, if anyone has a pointer to (3), let me know ron
Re: [9fans] look and feel for iwp9
ron, look at http://9fans.net/archive/2006/11/59. There are more mails in 2006/11 and 2006/10 about TeX and iwp9. Probably you migth convert the lyx format to TeX (LaTeX) and apply that header. slds. ron minnich escribió: noble goal: look like plan 9 docs ways to goal: 1. troff 2. tex with the right macros 3. lyx with the right layouts so I have this paper written in lyx, if anyone has a pointer to (3), let me know ron
Re: [9fans] sad commentary
Die, thread die!
Re: [9fans] look and feel for iwp9
Note: I copied the source request from an older iwp9 call. I think the original idea was to be able to electronically produce the entire proceedings book, with a uniform layout, page numbers, toc etc. I am not sure how this worked out, especially if different people eventually submitted source files of different nature. But do not worry: Worst case, the physical book will be produced by printing (or copying) the pdf's (which should more or less look like plan9 docs) on white pages with the right numbers pre-printed on them, and by preparing the toc by hand. I think this was done for the 1st iwp9 as well. So, please do not pay too much attention to the source requirements, this was definitely not meant to make life (more) complicated. I can also remove this requirement completely, if you think it might discourage people. Spyros Rodolfo kix Garcia wrote: ron, look at http://9fans.net/archive/2006/11/59. There are more mails in 2006/11 and 2006/10 about TeX and iwp9. Probably you migth convert the lyx format to TeX (LaTeX) and apply that header. slds. ron minnich escribió: noble goal: look like plan 9 docs ways to goal: 1. troff 2. tex with the right macros 3. lyx with the right layouts so I have this paper written in lyx, if anyone has a pointer to (3), let me know ron
Re: [9fans] p9p vbackup on linux
Adding those lines verbatim to a file 'config', I then ran: vnfs -c 16k config and got back: handle da...0d I don't yet fully understand the implications of that 16 char hex string, so I'm not posting it here, but I didn't seem to need it anywhere else. It was just a debugging print. It's the root handle that clients need to know to connect to the NFS server. It used to be randomly generated each time vnfs started, but I found it was much easier to use a fixed one. The bytes you didn't post are the first 8 bytes of sha1sum /dev/zero. On my venti server, I got a *lot* of these messages: venti/venti: bucket overflow XXX but I think I understand that (this is a junk venti server used for experimentation, so i didn't spend any time sizing things appropriately) Right, your index is too small. 4)It looks like libdiskfs allows vnfs to serve up arbitrary disk image formats (hfs, ffs, ufs, c), which is awesome, but it'd be nice if it could also serve vac snapshots. Anything peculiar about vac that inhibits this, or is it just a matter of extra code in libdiskfs (or in vnfs, to switch between libdiskfs and something for vac)? Better to just use vacfs -m if you want to view vac, and skip NFS entirely. NFS doesn't let you see close events, so you have to make up handles that can last an arbitrarily long time. This is pretty easy if you're serving a fixed set of Unix file system disk images: the handle specifies the particular disk image and the inode in that disk image. There's no similarly easy handle to use for vac archives. (Also remember that the handle has to have enough information to make dotdot work!) Also, vac -a is a viable alternative to vbackup, and it lets you exclude certain directories or files from the backup. Russ
Re: [9fans] p9p vbackup on linux
// The bytes you didn't post are the first 8 bytes of // sha1sum /dev/zero. Hey! How do you know what's in my /dev/zero? // Better to just use vacfs -m if you want to view vac, // and skip NFS entirely. To the extent that I just (or primarialy) want to see vac dumps, sure. The idea was having a single location for the variety of image types. Also, doing so with NFS allows me to do it on a wide variety of Unix hosts with no modifications or even installed software. Of course, having played with it for a few days now, I'll likely just end up doing vac dumps anyway. -a just makes it that much more compelling. Anthony
Re: [9fans] vx32 and 9vx performance, and on x86-64
* the kprocdev framework. all i/o into devip, devfs, and devdraw is marshalled and handed off to a kproc running in a different pthread, so that blocking i/o won't block the cpu0 pthread, which is the only one that can run vx32. this means that all i/o gets copied one extra time inside the kernel. why can only one thread run vx32? - erik
Re: [9fans] sftpfs
On 2008-Jul-2, at 14:10 , Fazlul Shahriar wrote: I wrote a file server for the SSH File Transfer Protocol (SFTP). You can find it here: Well done! It's nice to see some people still prefer writing code instead of mail ;-) I'll give it a beating as soon as I have a free moment. --lyndon
Re: [9fans] vx32 and 9vx performance, and on x86-64
why can only one thread run vx32? i think i found part of the answer just now. see the comment above 9vx/main.c:^setsigsegv
Re: [9fans] vx32 and 9vx performance, and on x86-64
* the kprocdev framework. all i/o into devip, devfs, and devdraw is marshalled and handed off to a kproc running in a different pthread, so that blocking i/o won't block the cpu0 pthread, which is the only one that can run vx32. this means that all i/o gets copied one extra time inside the kernel. why can only one thread run vx32? 9vx requires that the page fault handler runs on an alternate stack during vx32 (user) execution and on the kernel stack during kernel execution. That bit--whether or not to run the signal handler on the pthread's alternate signal stack--is part of the struct sigaction defining the signal-handling behavior, which is shared by all pthreads in the process, not per-pthread. 9vx arranges that the global bit is correct for all pthreads by only allowing one of the pthreads--cpu0--to page fault. The others, which run supporting kprocs, arrange never to fault. When user i/o is moved off cpu0 to the supporting kprocs, the i/o has to be done into fault-free kernel buffers and then copied back into user space on cpu0. This is essentially a failure of vision in the pthreads interface: sigaltstack is per-pthread, but sigaction is not. Linux does make it possible to have different sigactions per pthread, but you'd have to hack up your own thread library. If the Linux guys had really understood the wisdom of rfork, one could just do rfork(RFSIGHAND) at the start of each new pthread instead of having to drag in a whole new library. FreeBSD didn't get this right either, for what it's worth. In both cases you could work around this by linking with a modified pthread library. Ironically, OS X doesn't have this problem because its signal handling was so bad 9vx has to reimplement it from scratch in terms of Mach exceptions (see 9vx/osx/signal.c). There are other simplifying assumptions, like having just one address range for the user address space, but they could be removed if necessary. The real difficulty is the sigaction SA_ONSTACK bit. None of this is terribly important for performance: right now there are plenty of inefficiencies not related to having just one cpu on which to run user code. Russ
[9fans] venti survery results
The venti surveys have stopped trickling in. As promised, here is a summary. Below is a table summarizing the venti data. Each line is one server that someone submitted. I am surprised that there are people out there with 4+ year old servers. You take very good care of your disks. I suspect that most of the large but new servers replaced older ones. Most people who replied had less than 2 million blocks, and I suspect most people who didn't reply have servers like the bottom half of the table rather than the top half. You could keep a million-block index in 50 MB of memory and do away with the index hash table completely. It might be worth having venti detect when the index cache can fit the entire index and operate entirely out of the cache, without ever needing to read from the hash table. You could get much better performance out of venti doing that, and not even need a bloom filter. In fact, in that mode you wouldn't even need to configure an index disk. Then there are the power users, with their tens or hundreds of millions of blocks. One GB of index cache only gets you thirty million index entries, so these people have essentially no choice but to maintain the hash table index with its heavy seek penalties. Maybe in a few years flash storage will save the day. Russ GB GBdays clumpscclumpsraw compr age 338708170 279714997 1158.6 593.4 681 most clumps 243894713 207350734 5614.7 1657.269 most bytes 148582718 105977246 447.2 186.5 561 45255915 23277726 135.0 87.0 169 27395797 15624078 95.9 62.9 7 22095841 12085340 78.9 53.466 10194765603 38.8 22.7 - 79912306622335 34.4 17.3 1768 66186702068276 46.2 39.560 61588244209478 37.7 21.2 1780 59711294325778 40.4 23.8 361 58055502246660 40.2 30.441 49005433749792 23.4 12.2 132 4151139 274551 31.3 30.4 214 24651711065357 16.3 12.4 1044 1756289 324119 12.6 11.4 1984 oldest 1544611 17057 23.4 23.3 359 1353686 9018962.41.1 - 1308981 9817607.34.0 1413 127972510738077.23.1 1544 1197798 9615546.83.3 1436 1136953 6092356.74.8 220 1082686 9717966.91.9 1119 837292 3472635.54.2 239 834808 5492865.33.2 1164 742362 6096424.11.8 490 641818 4577843.82.2 1631 slowest growth 279319 2228981.60.8 - 250992 1681721.40.8 547 238121 2150401.40.5 268 213772 1837951.20.542 151431 1340910.90.4 108 141257 1218090.80.3 208 122807 1052750.60.332 70 670.00.0 0 newest
[9fans] 9pfuse SETXATTR misunderstanding
Apparently GNU mv is fond of extended attributes, and keeps breaking 9pfuse when I try to move a file between directories. This is the culprit: src/cmd/9pfuse/fuse.c:175:case FUSE_SETXATTR: src/cmd/9pfuse/fuse.c:176:/* struct and two strings */ In fact, SETXATTR comes with one string (the name of the attribute), and one blob of arbitrary data (the length of which is given in the fuse_setxattr_in struct). So: src/cmd/9pfuse/fuse.c:179:|| ((char*)m-tx)[m-hdr-len-1] != 0 the last byte of a well-formed message is not guaranteed to be NUL, and this check is not sensible. Suggested fix (which works locally): --- fuse.c 7 Nov 2007 22:31:22 - 1.11 +++ fuse.c 4 Jul 2008 04:57:15 - @@ -173,10 +173,9 @@ goto bad; break; case FUSE_SETXATTR: - /* struct and two strings */ + /* struct, one string and one binary blob */ if(m-hdr-len = sizeof(struct fuse_setxattr_in) - || ((char*)m-tx)[m-hdr-len-1] != 0 - || memchr((uchar*)m-tx+sizeof(struct fuse_setxattr_in), 0, m-hdr-len-sizeof(struct fuse_setxattr_in)-1) == 0) + || ((char*)m-tx)[m-hdr-len-1-((struct fuse_setxattr_in*)m-tx)-size] != 0) goto bad; break; Dropped the memchr as it is clearly satisfied by the previous condition. -sqweek
