headers
Alan L. Cox | 2 Mar 2003 06:48

Removal of ENABLE_VFS_IOOPT

Before I begin work on vm_object locking, I'd like to remove
ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
work-in-progress by John Dyson to perform zero-copy file system I/O. 
Unfortunately, it still has some unresolved issues, and no one has taken
an active interest in fixing them.

For the record, both Matt Dillon and Tor Egge have stated in public or
private e-mail that they favor removing it.
Unless I hear an objection, I intend to remove it in a few days.

Alan

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 10 comments |
headers
Jeff Roberson | 2 Mar 2003 07:01

Re: Removal of ENABLE_VFS_IOOPT

On Sat, 1 Mar 2003, Alan L. Cox wrote:

> For the record, both Matt Dillon and Tor Egge have stated in public or
> private e-mail that they favor removing it.
> Unless I hear an objection, I intend to remove it in a few days.
>

I'm all for it.

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 0 comments |
headers
Poul-Henning Kamp | 2 Mar 2003 10:10
Picon
Favicon

Re: Removal of ENABLE_VFS_IOOPT

In message <3E619B26.DF1E4FC7 <at> imimic.com>, "Alan L. Cox" writes:
>Before I begin work on vm_object locking, I'd like to remove
>ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
>work-in-progress by John Dyson to perform zero-copy file system I/O. 
>Unfortunately, it still has some unresolved issues, and no one has taken
>an active interest in fixing them.
>
>For the record, both Matt Dillon and Tor Egge have stated in public or
>private e-mail that they favor removing it.
>Unless I hear an objection, I intend to remove it in a few days.

Kill it!

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 0 comments |
headers
Poul-Henning Kamp | 2 Mar 2003 17:14
Picon
Favicon

caddr_t, d_ioctl_t and cdevsw{} in general.


>des         2003/03/02 07:29:13 PST
>
>  FreeBSD src repository
>
>  Modified files:
>    sys/sys              uio.h 
>    sys/kern             kern_subr.c 
>  Log:
>  Convert one of our main caddr_t consumers, uiomove(9), to void *.

One of the other ones are cdevsw->d_ioctl(), where I would really
like to make the pointer argument a "void *".

Unfortunately, we have approx 140 statically initialized instances
of struct cdevsw {} in our tree, so any modification to this structure
makes a major mess and flagday, and 's/caddr_t[ ]*/void */' is not
sufficient reason alone.

(The worry that we may break source compatibility with previous
FreeBSD's or other operating systems is likely false economy because
SMPng may change semantics so much that any such compatibility at
best is illusory.)

There are other changes to struct cdevsw{} which are pending, I just
eliminated the d_psize element for instance, and we probably need to
pass a file descriptor to d_open(), d_close() and possibly d_ioctl()
in the future.

My intent is to postpone any flag-day for as long as I can, but if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Lambert | 2 Mar 2003 18:36
Picon

Re: Removal of ENABLE_VFS_IOOPT

"Alan L. Cox" wrote:
> Before I begin work on vm_object locking, I'd like to remove
> ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
> work-in-progress by John Dyson to perform zero-copy file system I/O.
> Unfortunately, it still has some unresolved issues, and no one has taken
> an active interest in fixing them.
> 
> For the record, both Matt Dillon and Tor Egge have stated in public or
> private e-mail that they favor removing it.
> Unless I hear an objection, I intend to remove it in a few days.

Here's an idea... ask John Dyson about it.

-- Terry

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 4 comments |
headers
Peter Wemm | 2 Mar 2003 19:53

Re: Removal of ENABLE_VFS_IOOPT

"Alan L. Cox" wrote:
> Before I begin work on vm_object locking, I'd like to remove
> ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
> work-in-progress by John Dyson to perform zero-copy file system I/O. 
> Unfortunately, it still has some unresolved issues, and no one has taken
> an active interest in fixing them.

Hold on a second..  I thought the zero-copy folks fixed this up and it
is required for turning on zero-copy mode etc.

I remember they added code to fix the read() coherency problems.

Cheers,
-Peter
--
Peter Wemm - peter <at> wemm.org; peter <at> FreeBSD.org; peter <at> yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 2 comments |
headers
Steve Kargl | 2 Mar 2003 19:58
Picon

Re: Removal of ENABLE_VFS_IOOPT

On Sun, Mar 02, 2003 at 09:36:51AM -0800, Terry Lambert wrote:
> "Alan L. Cox" wrote:
> > Before I begin work on vm_object locking, I'd like to remove
> > ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
> > work-in-progress by John Dyson to perform zero-copy file system I/O.
> > Unfortunately, it still has some unresolved issues, and no one has taken
> > an active interest in fixing them.
> > 
> > For the record, both Matt Dillon and Tor Egge have stated in public or
> > private e-mail that they favor removing it.
> > Unless I hear an objection, I intend to remove it in a few days.
> 
> Here's an idea... ask John Dyson about it.
> 

From John's comments in c.u.b.f.m, I doubt he
follows the kernel development in 5.0 close enough
to make any recommendation without studying the 
code.  I further suspect that John would not want
to spend the time require.

--

-- 
Steve

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 3 comments |
headers
Terry Lambert | 2 Mar 2003 20:11
Picon

Re: Removal of ENABLE_VFS_IOOPT

Steve Kargl wrote:
> > Here's an idea... ask John Dyson about it.
> 
> From John's comments in c.u.b.f.m, I doubt he
> follows the kernel development in 5.0 close enough
> to make any recommendation without studying the
> code.  I further suspect that John would not want
> to spend the time require.

It's a design question, not an implementation question.  Alan's
suggestion is that the design be modified because (in his opinion)
the implementation is incomplete.

Though Peter Wemm's comment that it is not incomplete, and that
it's used by the zero copy TCP people, to the extent that they've
maintained the read coherency code, is also salient.

BTW: I think you are wrong about John; I guess you missed his
post to -chat last week?

-- Terry

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 2 comments |
headers
Steve Kargl | 2 Mar 2003 20:44
Picon

Re: Removal of ENABLE_VFS_IOOPT

On Sun, Mar 02, 2003 at 11:11:12AM -0800, Terry Lambert wrote:
> Steve Kargl wrote:
> > > Here's an idea... ask John Dyson about it.
> > 
> > From John's comments in c.u.b.f.m, I doubt he
> > follows the kernel development in 5.0 close enough
> > to make any recommendation without studying the
> > code.  I further suspect that John would not want
> > to spend the time require.
> 
> It's a design question, not an implementation question.  Alan's
> suggestion is that the design be modified because (in his opinion)
> the implementation is incomplete.

I suppose Alan's suggestion to remove the code is a
modification to the design. :-)

> BTW: I think you are wrong about John; I guess you missed his
> post to -chat last week?

I don't read -chat.  I do read c.u.b.f.m and John's
statements leads one to conclude he doesn't follow
the development close enough to make a design decision.

--

-- 
Steve

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan L. Cox | 2 Mar 2003 21:29

Re: Removal of ENABLE_VFS_IOOPT

Peter Wemm wrote:
> 
> "Alan L. Cox" wrote:
> > Before I begin work on vm_object locking, I'd like to remove
> > ENABLE_VFS_IOOPT from the kernel sources.  ENABLE_VFS_IOOPT was a
> > work-in-progress by John Dyson to perform zero-copy file system I/O.
> > Unfortunately, it still has some unresolved issues, and no one has taken
> > an active interest in fixing them.
> 
> Hold on a second..  I thought the zero-copy folks fixed this up and it
> is required for turning on zero-copy mode etc.
> 
> I remember they added code to fix the read() coherency problems.
> 

No, they didn't.  The zero-copy sockets code introduced a new page-based
copy-on-write mechanism and a new parameter to uiomoveco()
("disposable") that guaranteed that the new mechanism wouldn't be used
for ENABLE_VFS_IOOPT.  In contrast, ENABLE_VFS_IOOPT tried to use the
preexisting object-based copy-on-write mechanism.  Except for a few
lines of code in kern_subr.c's userspaceco(), the two mechanisms are
distinct.  Specifically, the page flipping logic is totally distinct:
vm_pgmoveco() for zero-copy sockets and vm_uiomove() for
ENABLE_VFS_IOOPT.

Someday, someone could attempt to reimplement ENABLE_VFS_IOOPT using the
page-based mechanism, in which case, the four snippets of code in
ffs_vnops.c could be useful.  Aside from that, the code which lives in
vm_map.* and vm_object.* is dead weight.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane