NetBSD & FreeBSD kernel API sync (incomplete proposal)
Jaromír Doleček
here is random set of things I faced. The list of differences is
surely not exhausive, feel free to comment on what should be added.
Note this is kernel API only.
It would be really cool to haggle whether FreeBSD changes would be
usable also for us or if we have superior interface. List of latter
things would then be forwarded to them so that they could consider
adapting their API to ours.
SQUEUE (N) vs. STAILQ (F) STAILQ seems like better name, but ..
hzto() vs. tvtohz()
time.h: timer*() vs. timeval*() macros (FreeBSD timeval*() also take
one less argument)
hashinit() doesn't take 'flags' on FreeBSD, IMHO should
VOP_UNLOCK(), vget(), vn_lock() take additional 'proc *' parameter on FBSD
FreeBSD: socket protosw: pru_usrreq is obsolete, there is new
pru_usrreqs with explicit array of function pointers - FWIW,
I think traditional BSD (and NetBSD) pru_usrreq makes it easier
to NOT implementing some of the ops, and we have the so*() functions
anyway, so it doesn't look like very usable change to me ..
they also add (equivalent of) PRU_POLL
so*() take additional 'proc *' parameter (last one)
NetBSD lacks dup_sockaddr()
there is no equivalent to FreeBSD time_second on NetBSD I'm aware of
- probably just use mono_time.tv_sec ?
asleep(), await() in FreeBSD - I think those are unnecessary and code
actually of need of them is actually broken and should be fixed (so
I don't think those should appear on NetBSD)
It would be really nice if they would sync lockmgr() changes,
there is some code (namely FreeBSD smbfs), which implements it's own
spin locks where ones provided by NetBSD lockmgr() would do nicely.
Do people have any opinions on what interface for above mentioned things
makes better sense, so that we can pick it and try hard to use same
on both true *BSD's ?
Jaromir
--
Jaromir Dolecek <jdol...@NetBSD.org> http://www.ics.muni.cz/~dolecek/
@@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@
Jason R Thorpe
> It would be really nice if they would sync lockmgr() changes,
> there is some code (namely FreeBSD smbfs), which implements it's own
> spin locks where ones provided by NetBSD lockmgr() would do nicely.
Ross and I painstakenly improved the NetBSD lockmgr(). Please do NOT
pull *ANY* FreeBSD changes to this function into the tree without
checking with both of us first.
--
-- Jason R. Thorpe <tho...@zembu.com>
Jason R Thorpe
> It would be really nice if they would sync lockmgr() changes,
> there is some code (namely FreeBSD smbfs), which implements it's own
> spin locks where ones provided by NetBSD lockmgr() would do nicely.
Actually... what would the FreeBSD smbfs be using spinlocks for? I could
understand simplelocks, but lockmgr-style spinlocks don't exactly make
sense (you should always have a process context in a file system).
Matthew Jacob
I'd have to second Jason's comment. There's a lot of different kinds of lock
stuff all throughout the FreeBSD kernel, but none with any comprehensive
architecture or plan at this time. Anyway, all if it is being deprecated as
the BSDi && FreeBSD code is merged. So- there's no direct reason I can see to
pull anything like this into NetBSD right now.
Jonathan Stone
>On Sat, Jul 22, 2000 at 05:51:12PM +0200, Jaromír Doleček wrote:
>
> > It would be really nice if they would sync lockmgr() changes,
> > there is some code (namely FreeBSD smbfs), which implements it's own
> > spin locks where ones provided by NetBSD lockmgr() would do nicely.
>
>pull *ANY* FreeBSD changes to this function into the tree without
>checking with both of us first.
I think he's suggesting that FreeBSD incorporate your improvements.
Wouldn't that be a good thing?
Jaromír Doleček
> > It would be really nice if they would sync lockmgr() changes,
> > there is some code (namely FreeBSD smbfs), which implements it's own
> > spin locks where ones provided by NetBSD lockmgr() would do nicely.
>
> Ross and I painstakenly improved the NetBSD lockmgr(). Please do NOT
> pull *ANY* FreeBSD changes to this function into the tree without
> checking with both of us first.
I'm not proposing we should pull up their lockmgr(). I'm proposing they
should pull up ours, since it's much improved and stable :)
Jaromír Doleček
> Actually... what would the FreeBSD smbfs be using spinlocks for? I could
> understand simplelocks, but lockmgr-style spinlocks don't exactly make
> sense (you should always have a process context in a file system).
There is also some networking code as part of the smbfs. I don't
pretend I understand it completely - I worked on making it compilable
at this moment :) It uses some "spinlocks" and looked like it could
just use lockmgr(LK_SPIN). On the second read, it seems like it's
actually technically doing regular lock with tsleep(), i.e. equivalent
of lockmgr(LK_SHARED).