> > > I'd like to move and rename them as I said in my previous mail,
> > > <sys/acpi.h> -> <sys/dev/acpi/acpi.h>
> > >   shared by both kernel and userland programs
> > > <sys/dev/acpi/acpi.h> -> <sys/dev/acpi/acpivar.h>
> > >   shared within kernel code (acpi stuff and related drivers)
> > 
> > IMHO, it's desirable to use the name "acpi.h", because of conflict
> > with the file dumped by /usr/sbin/config.
> > 
> > I love :
> >   fooreg.h : device dependent and implementation independent
> >              structures, macros, and others.
> >   foovar.h : implementation dependent ones.
> Thanks Shiozaki-san, I think `reg' is short for registers of the
> target chip, correct?  In ACPI's case, PM1 register and some such
> and maybe definitions for ACPI tables.
> How about kernel/userland shareable stuff like ioctl?  for example,
> usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h.
> Is this a special case violating the guideline?
> I think we can distinguish them like "usb.h" and <dev/usb/usb.h>,
> also we will stop generating acpi.h in kernel build directory.

Typically you would have:

acpivar.h       Data structures defined by implementation
acpireg.h       Data structures defined by interface
acpiio.h        Interface to userland

Since we're all in agreement, I'll move to these.

... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to