headers
David Holland | 10 Mar 2008 07:11
Picon

Updates/clarifications/adjustments to BUILDING

A few things in BUILDING have gone out of date, and also, some things
that should be are not documented (e.g. how build.sh -u interacts with
kernel=foo). I have done an editing pass and propose the following
patch.

The highlights:
   - mention src/tests and reference atf;
   - provide examples of MACHINE and MACHINE_ARCH -- someone please
     double-check these to make sure I haven't lied;
   - mention that MKOBJ=no is not recommented;
   - correct the default setting of USETOOLS;
   - document the interaction of build.sh -[uo] with various things;
   - document the interaction of build.sh tools and kernel=foo;
   - various typo fixes and wording adjustments, and use fewer
     parentheses.

Index: BUILDING.mdoc
===================================================================
RCS file: /cvsroot/src/doc/BUILDING.mdoc,v
retrieving revision 1.55
diff -U 10 -r1.55 BUILDING.mdoc
--- BUILDING.mdoc	8 Mar 2008 14:48:57 -0000	1.55
+++ BUILDING.mdoc	10 Mar 2008 05:59:47 -0000
 <at>  <at>  -120,23 +120,30  <at>  <at> 
 use the
 .Nx
 .Xr make 1
 .Dq reachover
 Makefile semantics when building these programs for a native host.
 .It Sy distrib/ , etc/
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hubert Feyrer | 10 Mar 2008 09:35
Picon
Favicon

Re: Updates/clarifications/adjustments to BUILDING

On Mon, 10 Mar 2008, David Holland wrote:
> A few things in BUILDING have gone out of date, and also, some things
> that should be are not documented (e.g. how build.sh -u interacts with
> kernel=foo). I have done an editing pass and propose the following
> patch.

Cool! Can you see if the NetBSD Guide needs any associated changes?

  - Hubert
Permalink | Reply | 0 comments |
headers
Alan Barrett | 10 Mar 2008 11:34
Gravatar

Re: Updates/clarifications/adjustments to BUILDING

On Mon, 10 Mar 2008, David Holland wrote:
> A few things in BUILDING have gone out of date, and also, some things
> that should be are not documented (e.g. how build.sh -u interacts with
> kernel=foo). I have done an editing pass and propose the following
> patch.

Almost all this looks good.  However,

>  .It Sy regression-tests
>  Can only be run after building the regression tests in the directory
>  .Dq regress .
> -Runs the compiled regression tests on the local host.
> +Runs those compiled regression tests on the local host.
> +Note that most tests are now managed instead using
> +.Xr atf 7 ;
> +this target will disappear when all tests have been migrated.

I think it would be better if this target ran both the old regression
tests and the new atf tests.  I see no need for the target to disappear.

--apb (Alan Barrett)
Permalink | Reply | 2 comments |
headers
Martin Husemann | 10 Mar 2008 11:39
Picon

Re: Updates/clarifications/adjustments to BUILDING

On Mon, Mar 10, 2008 at 12:34:17PM +0200, Alan Barrett wrote:
> I think it would be better if this target ran both the old regression
> tests and the new atf tests.  I see no need for the target to disappear.

Running the old regression tests is mostly useless. You need to run some
of them as root (and there is no automation to do that), others can not
be run as root. And there is no way to tell if something worked besides 
reading the source, for many of them.

Martin
Permalink | Reply | 0 comments |
headers
David Holland | 10 Mar 2008 11:49
Picon

Re: Updates/clarifications/adjustments to BUILDING

On Mon, Mar 10, 2008 at 12:34:17PM +0200, Alan Barrett wrote:
 > Almost all this looks good.  However,
 > 
 > >  .It Sy regression-tests
 > >  Can only be run after building the regression tests in the directory
 > >  .Dq regress .
 > > -Runs the compiled regression tests on the local host.
 > > +Runs those compiled regression tests on the local host.
 > > +Note that most tests are now managed instead using
 > > +.Xr atf 7 ;
 > > +this target will disappear when all tests have been migrated.
 > 
 > I think it would be better if this target ran both the old regression
 > tests and the new atf tests.  I see no need for the target to disappear.

That is probably true; want to fix the toplevel makefile to run the
atf tests? (I suppose it should run them out of $DESTDIR, and fail if
crossbuilding...)

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 15 Mar 2008 13:53

document to add to internals book? (was re: Accessing a hardware device)

The following was on netbsd-users. Would this be useful to add to the 
NetBSD Internals book (htdocs/docs/internals/en/) to start "my first 
NetBSD device driver"?

(I bcc'd a few developers who work on that book.)

On Sat, 15 Mar 2008, Toru Nishimura wrote to netbsd-users:

> Date: Sat, 15 Mar 2008 21:35:27 +0900
> From: Toru Nishimura <locore64 <at> alkyltechnology.com>
> To: netbsd-users <at> netbsd.org
> Subject: re: Accessing a hardware device
> 
> David Dudley asked;
> 
> > I've got an application where I need to access the hardware registers
> > of a specific PCI device.  This device doesn't have a driver associated
> > with it (and my application doesn't need one either), and the
> > application is planned to handle direct interface to the hardware.
> 
> It should be a rather easy task, just as you expect, a sort of "my first
> NetBSD device driver" practice.  All you want is a way to mmap
> PCI device register address range to your own program which
> knows and handles everything specific to the HW.
> 
> - It's necessary for you to have a small device driver anyway.  It provides
>   userland an entry point to acccess.  The program structure would
>   be like as below;
> 
>    fd = open("/dev/mypcihw", 2);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Husemann | 15 Mar 2008 20:50
Picon

Re: document to add to internals book? (was re: Accessing a hardware device)

On Sat, Mar 15, 2008 at 07:53:50AM -0500, Jeremy C. Reed wrote:
> The following was on netbsd-users. Would this be useful to add to the 
> NetBSD Internals book (htdocs/docs/internals/en/) to start "my first 
> NetBSD device driver"?

Yes!

Martin
Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 20 Mar 2008 23:42

should there be a manpage for every device? every kernel configuration interface attribute?

I often see names that don't have corresponding manual pages like "ra".

I think there should be a man page for every device.

I think there should be a man page for every kernel configuration 
interface attribute (I don't know if that is the right term, but I will 
show examples below.)

What do you think?

 m=`uname -m` ; dmesg |  egrep "^[^ ]+ at " |
 cut -d " " -f 1,3 | tr -d ":" | fmt 1 |
 sed -e 's,[0-9]$,,g' | sort -u | while read d ; do
  [ -e "/usr/share/man/man4/$d.4" ] ||
  [ -e "/usr/share/man/man4/$m/$d.4" ] || echo "$d needed" ; done

output on vax 4.0:

ibus needed
mscpbus needed
mtc needed
ra needed
rl needed
rlc needed
rx needed
uba needed

on amd64 HEAD:

cpu needed
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Holland | 21 Mar 2008 17:21
Picon

Re: should there be a manpage for every device? every kernel configuration interface attribute?

On Thu, Mar 20, 2008 at 05:42:27PM -0500, Jeremy C. Reed wrote:
 > I often see names that don't have corresponding manual pages like "ra".
 > 
 > I think there should be a man page for every device.

Yes.

(Would you like to have cron run that mail the results here once a
month or so? That would probably help get it done in the long run.)

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 3 comments |
headers
Hubert Feyrer | 21 Mar 2008 17:20
Picon
Favicon

Re: should there be a manpage for every device? every kernel configuration interface attribute?

On Fri, 21 Mar 2008, David Holland wrote:
> > I often see names that don't have corresponding manual pages like "ra".
> >
> > I think there should be a man page for every device.
>
> Yes.

seconded

> (Would you like to have cron run that mail the results here once a
> month or so? That would probably help get it done in the long run.)

Cron job is a nice idea...
I wonder if src/sys/dev/DEVNAMEs can be of any help ...

  - Hubert
Permalink | Reply | 0 comments |

Gmane