headers
Garance A Drosihn | 1 Jun 2004 01:48
Picon
Favicon

Re: Change to "kludge option processing" in /bin/ps

At 5:08 PM +0200 5/31/04, Cyrille Lefevre wrote:
>also, what about the proposed changes I have submitted ?

I never got an answer from the last two or three messages I sent
to you, so I am going ahead with bits of your changes and bits
of my own pending changes.

--

-- 
Garance Alistair Drosehn            =   gad <at> gilead.netel.rpi.edu
Senior Systems Programmer           or  gad <at> freebsd.org
Rensselaer Polytechnic Institute    or  drosih <at> rpi.edu
_______________________________________________
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 |
headers
Garance A Drosihn | 1 Jun 2004 05:36
Picon
Favicon

Re: Change to "kludge option processing" in /bin/ps

At 5:08 PM +0200 5/31/04, Cyrille Lefevre wrote:
>
>before to commit new changes, think about how to fix the
>following ones :)
>
># ps -p ,,
>   PID  TT  STAT      TIME COMMAND
>     0  ??  ZW     0:00.00  (sshd)
># psx -p ,,
>psx: no process id specified

The above issue was pretty trivial to fix, and I have committed a
change which should fix it.

--

-- 
Garance Alistair Drosehn            =   gad <at> gilead.netel.rpi.edu
Senior Systems Programmer           or  gad <at> freebsd.org
Rensselaer Polytechnic Institute    or  drosih <at> rpi.edu
_______________________________________________
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 |
headers
Kirk McKusick | 1 Jun 2004 04:17

Possible Discounts on Design and Implementation of the FreeBSD OS


------- Forwarded Message

Date:    Mon, 31 May 2004 20:35:56 -0400
From:    Ben Thomas <thomas <at> computer.org>
To:      mckusick <at> mckusick.com
Subject: fyi - Book discounts on D&I of FreeBSD OS

FWIW, bookpool.com generally offers discounts on many technical books.
Their approach is to buy in volume and pass on the savings. Indeed, they
often pass on savings on UPS rates to commercial addresses. I have found
them reputable, fast and dependable.

Example, your older book is currently 22% off. I don't recall at what
discount level I purchased it, but it was certainly at discount.

http://www.bookpool.com/.x/inw82iqyz8/ss/1?qs=mckusick&Go.x=0&Go.y=0&Go=Go

Pass this on if you find it a useful data point.

-b

------- End of Forwarded Message

_______________________________________________
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"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Leidinger | 1 Jun 2004 11:38
Favicon

Re: ether_crc32_[bl]e()

On Mon, 31 May 2004 11:20:57 -0600 (MDT)
"M. Warner Losh" <imp <at> bsdimp.com> wrote:

> In message: <20040531164514.GA7776 <at> green.homeunix.org>
>             Brian Feldman <green <at> freebsd.org> writes:
> : On Sun, May 30, 2004 at 06:42:11PM +0000, Christian Weisgerber wrote:
> : > NetBSD and OpenBSD have two helper functions in if_ethersubr.c
> : > 
> : > ether_crc32_le(const u_int8_t *buf, size_t len)
> : > ether_crc32_be(const u_int8_t *buf, size_t len)
> : > [...]
> : > The patch below adds the functions to if_ethersubr.c and, as an
> : > example, switches re(4) to make use of this.
> : > 
> : > 1. Do we want this?
> : 
> : Yeah :)
> 
> I think so too.  I had something like this on my list after I found a
> very badly implemented big endian crc routine whose provenance was in
> question.  So this is excellent timing.

Is someone interested in improving our IP checksum code too?

On i386 it uses assembly language which "works ok" with gcc 3.x (so
far), but it isn't guaranteed it will work with future versions of gcc.
Intels C compiler already has problems with it (and it's verified it's
because of bugs in the asm code), so in case of the use of icc a C
version is used.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian Feldman | 1 Jun 2004 17:19
Picon
Favicon

once again, MP-safe kqueue...

I haven't seen anything about further work being done on kqueue
recently, so I decided to go ahead and overhaul the implementation; it
now seems to solve all reported issues, i.e. it doesn't deimplement
EVFILT_PROC+NOTE_TRACK and allows recursing KNOTE() (knote()) calls.
However, it doesn't have deadlock avoidance, so consumers that do
that (mostly putting kqueues on kqueues) need to not cause ordering
reversals.

There is one subsystem lock still, just like the select(3) subsystem
uses one, but each klist uses that to implement a single reader/writer
recursive lock that is a subset of what lockmgr(9) can do.  In fact,
it is much like how vnodes are locked.  There can be one reader,
which must not sleep, signified by the thread pointer being NULL.
There can be one writer which may sleep and drop the kqueue subsystem
lock (klist interlock), signified by putting curthread in the klist's
owner thread pointer.

For knote (events), the kqueue subsystem (blocking) lock is acquired 
and then the klist is locked non-blockingly.  For kqueue_register,
the klist lock is blockingly acquired, which still works from
knote() because the klist has already been locked and it only
has to increase the recursion count.  The kevent system call uses
blocking acquisitions of knotes, but it does not sleep with them
held, so it does not set the ownership thread pointer.

Check out the following patch to try it out.  I notice no instability,
using kqueues heavily on SMP, and have reports of it functioning just
fine elsewhere.  Please let me know of any problems either conceptually
or in the implementation.
	<http://green.homeunix.org/~green/kqueue%2bvm.patch>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maxime Henrion | 1 Jun 2004 20:29
Picon
Favicon

The new dev sysctl tree

	Hi all,

Dag-Erling recently committed some code that makes it extremely easy
and convenient to have per-devices sysctl.  I changed the fxp(4)
driver to use this new framework for its sysctls, which allows to
remove a bit of code from this driver.

However, there is a significant drawback.  For instance, what used to
be "hw.fxp0.int_delay" is now called (on my box) :
"dev.root0.nexus0.acpi0.pcib0.pci0.fxp0.int_delay".  Obviously, this
is really too long to be convenient to use.  Furthermore, the name of
this sysctl is not unique anymore.  This is particularly annoying in
some cases.  For instance, if someone needs to boot without acpi while
he's using it the rest of the time, the sysctl won't be named the same.

So I made a patch to flatten this sysctl tree.  This doesn't cause any
conflict since attached drivers' names are unique.  As a consequence,
we lose the hierarchy information from the sysctl tree, however I
believe this isn't a problem since we can get this information with
devinfo(8) already.  If for some reason, we really need the hierarchy
information in this sysctl tree, I can easily add a .parent sysctl to
each device node.

I'm attaching the patch that flattens the sysctl tree to this mail.

Opinions are of course welcome, but please, this isn't a call for yet
another bikeshed of hell, so keep to the point.

Cheers,
Maxime
(Continue reading)

Permalink | Reply | 2 comments |
headers
Poul-Henning Kamp | 2 Jun 2004 08:56
Picon
Favicon

Re: The new dev sysctl tree

In message <20040601182949.GC9228 <at> elvis.mu.org>, Maxime Henrion writes:

>Dag-Erling recently committed some code that makes it extremely easy
>and convenient to have per-devices sysctl.  I changed the fxp(4)
>driver to use this new framework for its sysctls, which allows to
>remove a bit of code from this driver.
>
>However, there is a significant drawback.  For instance, what used to
>be "hw.fxp0.int_delay" is now called (on my box) :
>"dev.root0.nexus0.acpi0.pcib0.pci0.fxp0.int_delay". 

This is one of the major reasons why I hate Solaris device handling :-)

Flatten it please.

--

-- 
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.
_______________________________________________
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 |
headers
Dag-Erling Smørgrav | 2 Jun 2004 12:50
Picon
Gravatar

Re: The new dev sysctl tree

Maxime Henrion <mux <at> freebsd.org> writes:
> So I made a patch to flatten this sysctl tree.  This doesn't cause any
> conflict since attached drivers' names are unique.  As a consequence,
> we lose the hierarchy information from the sysctl tree, however I
> believe this isn't a problem since we can get this information with
> devinfo(8) already.

No objections from me.

>                      If for some reason, we really need the hierarchy
> information in this sysctl tree, I can easily add a .parent sysctl to
> each device node.

That would be nice.

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
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 |
headers
John-Mark Gurney | 3 Jun 2004 07:29
Favicon

Re: once again, MP-safe kqueue...

Brian Feldman wrote this message on Tue, Jun 01, 2004 at 11:19 -0400:
> I haven't seen anything about further work being done on kqueue
> recently, so I decided to go ahead and overhaul the implementation; it

I am waiting for information from work to confirm that I have permission
to commit the work that I have done on kqueue so far.

Once I have this go ahead, I'll release a patch that contains working
per-kqueue locks for PROC, pipes and VFS...  I have not tested AIO, and
the socket code can not reliably be locked until the socket code is
fixed to be locked properly...

I'll probe them tomorrow.

--

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
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 |
headers
M. Warner Losh | 3 Jun 2004 23:17

Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

In message: <xzp3c5c8i1w.fsf <at> dwp.des.no>
            des <at> des.no (Dag-Erling Smørgrav) writes:
: "M. Warner Losh" <imp <at> bsdimp.com> writes:
: > des <at> des.no (Dag-Erling Smørgrav) writes:
: > : "M. Warner Losh" <imp <at> bsdimp.com> writes:
: > : > How about an API?  How does the driver deal with the global/instance
: > : > variable split?  If I set dev.fxp.gerbil to 1 and dev.fxp.1.gerbil to
: > : > 23?  Is that order dependent?
: > : that's up to the driver author to decide.
: > That's why I want to know the API the driver will use so that it can
: > be judged as sufficient or not.  I also think we should have some kind
: > of default design pattern.
: 
: The API will be {devclass,device}_get_sysctl_{ctx,tree}().  The driver
: then adds children to these nodes using sysctl_add_*().

We're going to wind up with the same code in a bunch of drivers for
the global sysctls then.  It will look like

	if (!devclass_get_sysctl("foo"))
		add_global_sysctl("foo");
	add_local_sysctl(device_get_sysctl(), "foo");

This is going to lead to some drivers not having global settings for
some systclts.  The question that I was trying to ask is 'is this
desirable?'  Does it make sense to break symmetry like this?  Maybe it
does, but I guess I need to see what you do and play with it a little
with cbb to see how well it works in practice...

Warner
(Continue reading)

Permalink | Reply | 0 comments |

Gmane