Subject: Re: new x86/pio.h breaks vbetool
To: Andrew Doran <ad@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: current-users
Date: 10/30/2007 07:24:58
On Mon, Oct 29, 2007 at 05:55:06PM +0000, Andrew Doran wrote:
> On Mon, Oct 29, 2007 at 12:31:11PM -0500, jakllsch@kollasch.net wrote:
> 
> > src/sys/arch/x86/include/pio.h ... it used to have
> > (in-line) assembly that was used by, among other
> > things, pkgsrc/sysutils/vbetool.  vbetool now
> > won't compile.
> >
> > Additionally, the functions would be nice
> > to have available.  Easier than everything
> > providing their own implementation.
> 
> The presence of a kernel header does not mean that it's a published or
> stable API. It's unfortunate, but vbetool shouldn't be using machine/pio.h
> and it should be fixed.
>  
> > The commit message of rev 1.6 of pio.h
> > does not explain why these functions
> > are now just prototypes.
> 
> 1.6 		26-Sep-2007  	ad 
> 
> x86 changes for pcc and LKMs.
> 
> - Replace most inline assembly with proper functions. As a side effect
>   this reduces the size of amd64 GENERIC by about 120kB, and i386 by a
>   smaller amount. Nearly all of the inlines did something slow, or something
>   that does not need to be fast.
> - Make curcpu() and curlwp functions proper, unless __GNUC__ && _KERNEL.
>   In that case make them inlines. Makes curlwp LKM and preemption safe.
> - Make bus_space and bus_dma more LKM friendly.
> - Share a few more files between the ports.
> - Other minor changes.

I'm surprised about 2 things:

1) That removing the specific inlines from pio.h actually reduces
   code size.

2) That a userspace program has any need for these calls.

OTOH since nothing in pio.h has any compatibility issues, there is no
real reason for killing it.

	David

-- 
David Laight: david@l8s.co.uk