> 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, unambig
On Wed, 4 Jun 2014, Philip Guenther wrote:
> On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck wrote:
> > Matthew Dempsky 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
e.
> Oh, and no "static" functions in the kernel. They cause problems with
> ddb.
>
> Even inline functions?
>
> Miod Vallat wrote:
> > Matthew, you obviously did not spot the evil 9p/util.h yet. This file
> > ought to be named ozymandias.h.
>
> I
?
Miod Vallat wrote:
> Matthew, you obviously did not spot the evil 9p/util.h yet. This file
> ought to be named ozymandias.h.
I could do that ☺
I copied that file from earlier work of mine. I only actually need a
few macros in it, so I shall strip it down for the next version.
> Also, I
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.
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck 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 as the lock, but
On 04/06/2014, Philip Guenther 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 condition that the t
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 T
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
On 03/06/2014, Gilles Chehade 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 later when it's
> + args.msize = 1 << 20;
> + c = mount (MOUNT_P9P, argu[2], 0, &args);
> + if (c) err (1, "failed to mount");
> + return 0;
> +}
> diff --git a/sys/9p/9p.c b/sys/9p/9p.c
> new file mode 100644
> index 000..37c5ebd
> --- /dev/null
&g
, "usage: %s fd path", argu[0]);
+ args.fd = strtol (argu[1], 0, 10);
+ args.msize = 1 << 20;
+ c = mount (MOUNT_P9P, argu[2], 0, &args);
+ if (c) err (1, "failed to mount");
+ return 0;
+}
diff --git a/sys/9p/9p.c b/sys/9p/9p.c
new f
e associated
with the file".
With block size great enough to hold a full 9p stat structure, it now works.
Thanks for the help.
te that getdents() is used by some ports, so it must work
correctly too; you can't just hack around problems by changing readdir().
ls invokes those via fts_open() and related functions. It's used by
basically all BSD programs that might need to traverse a directory tree.
> Problem is t
On 31/05/2014, M Farkas-Dyck wrote:
> Problem is that directories in 9p customarily have length 0
Actually not; it also fails with size=(-1).
Sorry for the noise.
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
You pick. But before you do think about how to test it.
On 30 May 2014 19:19, "M Farkas-Dyck" wrote:
> Stefan Fritsch wrote:
> > [1] https://bitbucket.org/iru/o9fs/overview
>
> Thanks for the link; this could be useful.
>
> Bob Beck wrote:
> > So I'm certainly not averse to someone working on i
Stefan Fritsch wrote:
> [1] https://bitbucket.org/iru/o9fs/overview
Thanks for the link; this could be useful.
Bob Beck 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 into the tree
How would it be
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
wrote:
> > Yes, that's true. you *WILL* have awful crashing or hanging bugs to
> chase ;)
> >
> > Welcome to the midlayer. Wine bottles are optional but highly
>
> 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
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
wrote:
> > However, as we've seen with lots of things that touch vfs it's
> > pretty easy to ge
> 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.
ink 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 one can't h
On Thursday 29 May 2014 19:17:25, M Farkas-Dyck wrote:
> On 29/05/2014, Ted Unangst 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 o
On 29/05/2014, Ted Unangst 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 knowledg
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
If any interest, please tell me before using earlier code, as I now
have a later version, which I would post in that case.
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 someone
else wishes to do so. This is my first vfs code
28 matches
Mail list logo
