Well I got curious, and wrote a test program for my Linux RPi:
Doing the equivalent of what du(1) does (a recursive tree walk statting every
file) seemed to be about 15% faster with openat/fstatat than with open/lstat.
This was on a local drive (SD card).
Over 9p to my Plan 9 RPi from Linux it
All of what Brian said is true for 9front as well. If you want to see our code
implementation of this you can find
it in /sys/src/9/bcm/ether4330.c. The only difference is that 9front puts
firmware in /lib/firmware and not /sys/lib/firmware.
We do not provide the binary files ourselves you need
Please don't apologise Brian, thanks so much for this help.
Looking at my ether4330.c, those two entries for revisions 6 and 9 are present,
but I did a "walk | grep 43444" over the whole disk and I can't find anything
like those blob files anywhere. /lib/firmware is empty too.
I think I will
In response to Ron's mail. Still can not reply from my mail server.
I still don't quite understand what you are getting at.
I was focusing up on the linux interface (ie openat(int fd, char *path, int
flags, ...)) mapping of open fd to path. I see now as well that openat
specifies that the
Faster for any command that operates on dir trees such as diff, du, rm, tar.When I first looked at plan9, I was a bit surprised its open *didn’t* workthis way! May be because of this earlier thread on comp.unix.wizardshttps://groups.google.com/g/comp.unix.wizards/c/i8vapj9BAqs/m/FlNUK705I0UJ
Moody wrote:
"What you _would_ want for this would be the ability to walk from the existing
fd, however the limits of 9p walk make this a bit impossible to implement in a
great way in my opinion. "
Maybe the chan could keep two fids: the original walked fid, and an opened
clone of that fid?
Depending on the implementation of the file system, openat vs open can be more efficient if there’s a lot of metadata locking for file creation.Sent from my iPhoneOn Apr 6, 2024, at 1:36 PM, ron minnich wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a
I wouldn't call it obvious. :) It looks like there's at least a difference
in where the firmware blobs are kept. I don't really know how much difference
there is in the driver code, but I would expect that there would be a file in
/sys/src/9/bcm that is analogous to ether4330.c. But I'll
openat gives you the effect of 'cd path; open file' without having to cd. I
don't see a lot of benefit to it unless you're opening a lot of files at
that path.
My first reaction, assuming you have a lot of files in that directory, was
something like
bind /dir /n/x and then just open /n/x/file...
Hi Brian,
Thanks for your help, does it make a difference that I'm using 9front? I don't
even seem to have a /sys/lib/firmware directory, and I'm not sure I have a
ether4330.c either.
I'm sure it's obvious, but I'm a newcomer to Plan 9 and I apologise in advance
if I'm missing obvious
10 matches
Mail list logo
