In message <199810251908.TAA03091@etinc.com>  Dennis wrote:
> At 03:41 PM 10/25/98 -0500, Ted Lemon wrote:
> >
> >> Is netbsd to the point where *most" users are using the release, or are the
> >> majority still running -current .? We're considering
> >> re-porting to NetBSD...which we previously dropped because 
> >> everyone wanted -current which we could not realistically support.
> >
> >Hm.   The 1.3 release is almost a year old now.   We are expecting to
> >do a 1.3.3 release shortly, but if I were you, I'd target the 1.4
> >release - that should be out by mid-January, and if you have a driver
> >that works in 1.4, your driver will have a longer product life.   So
> >against your better judgement, I would suggest that you port to
> >-current.   If you don't want to support users running -current, wait
> >for 1.4 to ship, and support them on that.
> 
> yeah yeah. And back in the 1.1 days everyone said...wait for 1.2. thats
> part of 
> the problem.
> 
> Is 1.4 going to be so different from 1.3.3 that we should bypass what is
> currently
> stable? Its only a minor release (unless you use a different numbering
> system then
> the rest of the world), so why are you implying that it would be a waste of
> time to
> port to 1.3.3? 

How about defining a kernel API or ABI for LKM's (aka DDI/DKI) ?
I sent a patch a month for linking LKM's together. It already contains 
a hook to export a subset of the kernel symbols.
There needs to be some glue for accessing kernel-structures that may change,
but I think most drivers don't track the changes. (eg the get recompiled
but not changed).
This would make this discussion a mood point as writing to this would
enable to run the driver in the release versions and if major changes are
in the kernel on -current there has to be (another) compatibility function
for the LKM. (yes it needs versioning!!)
If we can agree on this I will be able to do most of the work in a short
time as I need it (work related) too.
I think comming up with a minimal set of functions/structures needed is 
the most timeconsuming (and boring) part.
We need:
	install support (eg. devsw & friends !!DYMAMIC devsw makes it a 
		    lot easier)
	spl/locks
	memory allocation
	busmap calls (no macro hacks for allocation at least !!)
	protection (suser() et al)
	abstraction for various 'sepcial' supsystems (if_ether, ttys, ...)
	....

Stefan

> 
> Also, if 1.4 is due out in 2 months, why are you doing a 1.3.3? It make
> little sense.
> 
> Dennis
> >
> >			       _MelloN_
> > 

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---