On 2014 Jun 04 (Wed) at 02:19:49 -0500 (-0500), strake...@gmail.com wrote:
:On Tue, Jun 03, 2014 at 10:44:57PM -0700, Philip Guenther wrote:
: Yes, some code I copied verbatim from plan9port or earlier work of mine,
: so that's fully in plan9 or my habitual style.
:
: IF YOU COPIED MORE THAN
On 04/06/2014, Philip Guenther guent...@gmail.com wrote:
The only reason to care whether another kernel thread had made it far
enough into tlseep as to be on a sleep queue is if it's calling wakeup()
on that thread's wait channel, but you MUST use some sort of lock to
protect that shared
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck strake...@gmail.com wrote:
Would a rwlock do? The sender and recver operate asynchronously, so
the sender needs to hold a lock while sending and release it when
asleep, but it can't be a mutex as the send operation may sleep, so I
used requ.ready
Matthew, you obviously did not spot the evil 9p/util.h yet. This file
ought to be named ozymandias.h.
Also, I am vetoing the addition of -fms-extensions to the kernel build
options. Whatever files require this option to build needs to be fixed
to be proper, unambiguous, C99, instead.
Matthew Dempsky matt...@dempsky.org wrote:
Also, look at man 9 style; in particular, OpenBSD doesn't put spaces around
-
Not in cited document, but noted.
Oh, and no static functions in the kernel. They cause problems with ddb.
Even inline functions?
Miod Vallat m...@online.fr wrote:
On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck strake...@gmail.com wrote:
Matthew Dempsky matt...@dempsky.org wrote:
Also, look at man 9 style; in particular, OpenBSD doesn't put spaces
around -
Not in cited document, but noted.
Read more of the existing kernel code.
Oh, and no static
On Wed, 4 Jun 2014, Philip Guenther wrote:
On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck strake...@gmail.com wrote:
Matthew Dempsky matt...@dempsky.org wrote:
Also, look at man 9 style; in particular, OpenBSD doesn't put spaces
around -
Not in cited document, but noted.
Read more of
Matthew, you obviously did not spot the evil 9p/util.h yet. This file
ought to be named ozymandias.h.
Also, I am vetoing the addition of -fms-extensions to the kernel build
options. Whatever files require this option to build needs to be fixed
to be proper, unambiguous, C99, instead.
I
the style(9) ... b :-)
On Fri, May 30, 2014 at 08:48:11PM -0500, strake...@gmail.com wrote:
One can actually read a file now! Yay!
I have another patch to allocate each message buffer from a pool as needed
rather than share one among all requests, but I'm not sure that it makes
sense
On 03/06/2014, Gilles Chehade gil...@poolp.org wrote:
the style(9) ... b :-)
Yes, some code I copied verbatim from plan9port or earlier work of
mine, so that's fully in plan9 or my habitual style. Other code I
wrote afresh in a bastard hybrid of KNF and my habitual style ☺
I'll KNFalize it
On Tue, 3 Jun 2014, strake...@gmail.com wrote:
Latest version, much unbroken. Mounted filesystem seems fully readable
now, but creation fails queerly: the file name is as long as the
requested name but garbage. I shall hack further...
First off, a utter blocker to this code being included in
One can actually read a file now! Yay!
I have another patch to allocate each message buffer from a pool as needed
rather than share one among all requests, but I'm not sure that it makes sense
to do so, as all requests go thru the same channel anyhow.
diff --git a/sbin/mount_9p/mount_9p.c
On Fri, May 30, 2014 at 10:42 PM, M Farkas-Dyck strake...@gmail.com wrote:
Ls seems to stat the directory and allocate a large enough dent
buffer. I couldn't find what ls calls to do so, but I assume that it's
a common function and other programs use it too.
opendir() and readdir() are the
On 31/05/2014, Philip Guenther guent...@gmail.com wrote:
opendir/readdir don't look at the st_size member, so I don't think any of
those will help. You haven't found the real problem yet.
Yes, I missed this in getdents docs:
nbytes must be greater than or equal to the block size associated
On Thursday 29 May 2014 19:17:25, M Farkas-Dyck wrote:
On 29/05/2014, Ted Unangst t...@tedunangst.com wrote:
The first question is why not use fuse? I think it's better to
have one userland filesystem interface than two.
We already have 2: fuse, nfs.
• 9p can operate over arbitrary
I actually agree that it might not be a bad thing.
However, as we've seen with lots of things that touch vfs it's pretty easy
to get to 80 or 90 percent
functionality and then the last 10% is a royal red pain in the butt, with
possibly awful crashing bugs.
So I'm certainly not averse to someone
However, as we've seen with lots of things that touch vfs it's
pretty easy to get to 80 or 90 percent functionality and then the
last 10% is a royal red pain in the butt, with possibly awful
crashing bugs.
The word possibly makes that sentence too optimistic.
Yes, that's true. you *WILL* have awful crashing or hanging bugs to chase ;)
Welcome to the midlayer. Wine bottles are optional but highly recommended.
On Fri, May 30, 2014 at 2:55 PM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
However, as we've seen with lots of things that touch vfs it's
Yes, that's true. you *WILL* have awful crashing or hanging bugs to chase ;)
Welcome to the midlayer. Wine bottles are optional but highly recommended.
And dual purpose.
1) drink it with pleasure in the company of a VFS hacker
2) when the midlayer breaks, beat the VFS hacker over the head
Most VFS hackers would say there is a third purpose. but don't scare him
away yet...
On Fri, May 30, 2014 at 3:01 PM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
Yes, that's true. you *WILL* have awful crashing or hanging bugs to
chase ;)
Welcome to the midlayer. Wine bottles are
Stefan Fritsch s...@sfritsch.de wrote:
[1] https://bitbucket.org/iru/o9fs/overview
Thanks for the link; this could be useful.
Bob Beck b...@obtuse.com wrote:
So I'm certainly not averse to someone working on it, but it would have to
be solid and with people to love it before it ever made it
You pick. But before you do think about how to test it.
On 30 May 2014 19:19, M Farkas-Dyck strake...@gmail.com wrote:
Stefan Fritsch s...@sfritsch.de wrote:
[1] https://bitbucket.org/iru/o9fs/overview
Thanks for the link; this could be useful.
Bob Beck b...@obtuse.com wrote:
So I'm
Ls seems to stat the directory and allocate a large enough dent
buffer. I couldn't find what ls calls to do so, but I assume that it's
a common function and other programs use it too. Problem is that
directories in 9p customarily have length 0, so ls says every such
directory empty. Getdents
If any interest, please tell me before using earlier code, as I now
have a later version, which I would post in that case.
On Thu, May 29, 2014 at 03:12, strake...@gmail.com wrote:
I have been writing a 9p vfs interface. Ultimately I hope to have this in
stock OpenBSD. So far it's incomplete and experimental and often faulty; I
shall hack it further when I have time, but meanwhile I post the diff here
in case
On 29/05/2014, Ted Unangst t...@tedunangst.com wrote:
The first question is why not use fuse? I think it's better to
have one userland filesystem interface than two.
We already have 2: fuse, nfs.
• 9p can operate over arbitrary transports, such as virtio and tcp. Fuse can't.
• To my knowledge
26 matches
Mail list logo
