headers
Edward Tomasz Napierała | 1 Nov 2010 12:45
Picon
Favicon

Re: Adapting FreeBSD to PSARC/2010/029.

Wiadomość napisana przez Tim Kientzle w dniu 2010-10-30, o godz. 07:17:
> On Oct 29, 2010, at 11:44 AM, Edward Tomasz Napierała wrote:
>> Currently, NFSv4 ACLs support in FreeBSD adheres to a draft by Sam Falkner
>> (it also complies with RFC3530, but that one leaves many things undefined).
>> Semantics for both UFS and ZFS is exactly the same.  With ZFS v28, the
>> semantics has changed; see the link below for details:
>> 
>> http://arc.opensolaris.org/caselog/PSARC/2010/029/20100126_mark.shellenbaum
> 
> I guess I need to get back to work on the NFSv4 ACL support for libarchive, eh?

Obviously :-)

> This is great.  Together with the acl_is_trivial_np() test function, the ACL
> support now makes a lot more sense.
> 
> The chmod(2) interaction, in particular, is a huge improvement.

I'm not sure about it.  I mean, yes, it's simpler - it's actually possible
to understand and remember how it works now - but from what I remember,
the problem with the old semantics and libarchive was that libarchive tried
to set file mode after restoring the ACL.  With draft semantics, this
resulted in malformed ACL.  With PSARC semantics, this results in no ACL
at all.

--
If you cut off my head, what would I say?  Me and my head, or me and my body?

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Petter Selasky | 1 Nov 2010 20:54
X-Face

[RFC] Outline of USB process integration in the kernel taskqueue system

Hi!

I've wrapped up an outline patch for what needs to be done to integrate the 
USB process framework into the kernel taskqueue system in a more direct way 
that to wrap it.

The limitation of the existing taskqueue system is that it only guarantees 
execution at a given priority level. USB requires more. USB also requires a 
guarantee that the last task queued task also gets executed last. This is for 
example so that a deferred USB detach event does not happen before any pending 
deferred I/O for example in case of multiple occurring events.

Mostly this new feature is targeted for GPIO-alike system using slow busses 
like the USB. Typical use case:

2 tasks to program GPIO on.
2 tasks to program GPIO off.

Example:

a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
>sc_task_on[1]);

b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
>sc_task_off[1]);

No matter how the call ordering of code-line a) and b), we are always 
guaranteed that the last queued state "on" or "off" is reached before the head 
of the taskqueue empties.
(Continue reading)

Permalink | Reply | 41 comments |
headers
Matthew Fleming | 1 Nov 2010 21:07
Picon

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
> Hi!
>
> I've wrapped up an outline patch for what needs to be done to integrate the
> USB process framework into the kernel taskqueue system in a more direct way
> that to wrap it.
>
> The limitation of the existing taskqueue system is that it only guarantees
> execution at a given priority level. USB requires more. USB also requires a
> guarantee that the last task queued task also gets executed last. This is for
> example so that a deferred USB detach event does not happen before any pending
> deferred I/O for example in case of multiple occurring events.
>
> Mostly this new feature is targeted for GPIO-alike system using slow busses
> like the USB. Typical use case:
>
> 2 tasks to program GPIO on.
> 2 tasks to program GPIO off.
>
> Example:
>
> a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
>>sc_task_on[1]);
>
>
> b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
>>sc_task_off[1]);
>
>
> No matter how the call ordering of code-line a) and b), we are always
(Continue reading)

Permalink | Reply | 37 comments |
headers
George Neville-Neil | 1 Nov 2010 20:20
Picon
Favicon

RFC: Updated ARP Queue patch...

Howdy,

This is marked as "Updated" because I first proposed this on arch <at>  but am now sending it to
a wider audience as I'm hoping to commit it in the near future.

Please review the following patch against HEAD:

http://people.freebsd.org/~gnn/head-arpqueue2.diff

This patch makes two changes to the ARP code:

1) It adds a sysctl configurable queue of packets that are held until an ARP reply is received or
timed out.

net.link.ether.inet.maxhold

Having the queue addresses a problem in modern systems where programs that use connectionless 
protocols for communication will suffer from dropping many packets when they start up or when
an ARP entry moves.

2) Makes the time we wait for an arp reply configurable via another sysctl.

net.link.ether.inet.wait

The old, pre 8.0, ARP code would run the timer once per second.  The new
ARP code sets a timeout of 20 seconds on each entry.  Neither value was specified
in RFC 826.  As a matter of fact, RFC 826 had this to say about timeouts:

"It may be desirable to have table aging and/or timeouts.  The
implementation of these is outside the scope of this protocol."
(Continue reading)

Permalink | Reply | 2 comments |
headers
Warner Losh | 3 Nov 2010 01:07

Re: [PATCH] Headers for the x86 subtree

From: Ulrich Spörlein <uqs <at> spoerlein.net>
Subject: Re: [PATCH] Headers for the x86 subtree
Date: Thu, 28 Oct 2010 22:58:15 +0200

> On Wed, 27.10.2010 at 16:56:06 +0200, Attilio Rao wrote:
> > This patch should convert a (simple and 100% shared between amd64 and
> > i386 header) under the x86 sub-tree. Please note that in this patch I
> > "svn cp" the file from sys/amd64/include/mptable.h into
> > sys/x86/include/mptable.h:
> > http://www.freebsd.org/~attilio/headers-x86.diff
> > 
> > This is someway a POC, that I really want to get in. The idea is
> > simple and someway follows the pc98 case (even if not entirely): the
> > files under machine/include/* became just mere stubs for x86/include/*
> > contents and redirect there.
> > This won't particulary help reducing the number of available files,
> > but generally removing verbatim and would also be the way to go for
> > handling MFCs.
> > If you find this is the right way I'll commit the fix and start moving
> > other files as time permits.
> 
> What I don't quite get with the new x86 directory is, why we didn't make
> it arch/x86 from the start? The usual argument against moving
> architecture specific stuff to arch/ is that it will break diffs for
> vendors. Now with x86 and the merging we are breaking their stuff
> anyway, but we don't actually improve the clutter under /sys and even
> gain a new arch-specific dir, not under arch/
> 
> Somehow, this seems like a missed opportunity for an often requested
> cleanup. :/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rui Paulo | 4 Nov 2010 08:42
Picon
Favicon

Re: RFC: Updated ARP Queue patch...

Hi,

On 1 Nov 2010, at 19:20, George Neville-Neil wrote:

> Howdy,
> 
> This is marked as "Updated" because I first proposed this on arch <at>  but am now sending it to
> a wider audience as I'm hoping to commit it in the near future.
> 
> Please review the following patch against HEAD:
> 
> http://people.freebsd.org/~gnn/head-arpqueue2.diff
> 
> This patch makes two changes to the ARP code:
> 
> 1) It adds a sysctl configurable queue of packets that are held until an ARP reply is received or
> timed out.
> 
> net.link.ether.inet.maxhold
> 
> Having the queue addresses a problem in modern systems where programs that use connectionless 
> protocols for communication will suffer from dropping many packets when they start up or when
> an ARP entry moves.
> 
> 2) Makes the time we wait for an arp reply configurable via another sysctl.
> 
> net.link.ether.inet.wait
> 
> The old, pre 8.0, ARP code would run the timer once per second.  The new
> ARP code sets a timeout of 20 seconds on each entry.  Neither value was specified
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Petter Selasky | 4 Nov 2010 09:38
X-Face

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote:
> On Monday 01 November 2010 22:14:49 John Baldwin wrote:
> > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote:
> > > Hi!
> > > 
> > > I've wrapped up an outline patch for what needs to be done to integrate
> > > the USB process framework into the kernel taskqueue system in a more
> > > direct way that to wrap it.
> > > 
> > > The limitation of the existing taskqueue system is that it only
> > > guarantees execution at a given priority level. USB requires more. USB
> > > also requires a guarantee that the last task queued task also gets
> > > executed last. This is for example so that a deferred USB detach event
> > > does not happen before any pending deferred I/O for example in case of
> > > multiple occurring events.
> > > 
> > > Mostly this new feature is targeted for GPIO-alike system using slow
> > > busses like the USB. Typical use case:
> > > 
> > > 2 tasks to program GPIO on.
> > > 2 tasks to program GPIO off.
> > > 
> > > Example:
> > > 
> > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
> > > 
> > > >sc_task_on[1]);
> > > 
> > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc-
> > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Petter Selasky | 4 Nov 2010 16:10
X-Face

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote:
> On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky <hselasky <at> c2i.net> 
wrote:
> > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote:
> >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky <hselasky <at> c2i.net>
> > 
> > wrote:
> >> > Hi!
> >> > 
> >> > I've wrapped up an outline patch for what needs to be done to
> >> > integrate the USB process framework into the kernel taskqueue system
> >> > in a more direct way that to wrap it.
> >> > 
> >> > The limitation of the existing taskqueue system is that it only
> >> > guarantees execution at a given priority level. USB requires more. USB
> >> > also requires a guarantee that the last task queued task also gets
> >> > executed last. This is for example so that a deferred USB detach event
> >> > does not happen before any pending deferred I/O for example in case of
> >> > multiple occurring events.
> >> > 
> >> > Mostly this new feature is targeted for GPIO-alike system using slow
> >> > busses like the USB. Typical use case:
> >> > 
> >> > 2 tasks to program GPIO on.
> >> > 2 tasks to program GPIO off.
> >> > 
> >> > Example:
> >> > 
> >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
> >> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Baldwin | 4 Nov 2010 15:29
Picon
Favicon

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote:
> On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky <hselasky <at> c2i.net> wrote:
> > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote:
> >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky <hselasky <at> c2i.net>
> > wrote:
> >> > Hi!
> >> >
> >> > I've wrapped up an outline patch for what needs to be done to integrate
> >> > the USB process framework into the kernel taskqueue system in a more
> >> > direct way that to wrap it.
> >> >
> >> > The limitation of the existing taskqueue system is that it only
> >> > guarantees execution at a given priority level. USB requires more. USB
> >> > also requires a guarantee that the last task queued task also gets
> >> > executed last. This is for example so that a deferred USB detach event
> >> > does not happen before any pending deferred I/O for example in case of
> >> > multiple occurring events.
> >> >
> >> > Mostly this new feature is targeted for GPIO-alike system using slow
> >> > busses like the USB. Typical use case:
> >> >
> >> > 2 tasks to program GPIO on.
> >> > 2 tasks to program GPIO off.
> >> >
> >> > Example:
> >> >
> >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc-
> >> >
> >> >>sc_task_on[1]);
> >> >>
(Continue reading)

Permalink | Reply | 33 comments |
headers
Hans Petter Selasky | 4 Nov 2010 20:08
X-Face

Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote:
> For the purpose of speed, I'm not opposed to breaking the KBI by using
> a doubly-linked TAILQ, but I don't think the difference will matter
> all that often (perhaps I'm wrong and some taskqueues have dozens of
> pending tasks?)

Hi,

In my case we are talking about 10-15 tasks at maximum. But still (10*9) / 2 = 
45 iterations is much more than 2 steps to do the unlink. Anyway. I will have 
a look at your work and suggest a new patch for my needs.

--HPS
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |

Gmane