Re: API/ABI rank of headers in /usr/include/isofs/cd9660

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

Hi,

Greg Troxel:
> >>   get rid of OBJDIR and DESTDIR
> They would be under /usr/obj after you run build.sh.

None to see:
  netbsd# ls -1 /usr/obj
  sys
  tooldir.NetBSD-6.1.3-i386
  tooldir.NetBSD-6.99.40-i386
  tools

> That's really all
> there is to the script, even though there is more text.  I was really
> just trying to sugges that you read the script as an illustrated example
> of build.sh usage.

Sure. I read. But as said, i don't understand / did not yet encounter
the problems which these settings will avoid.
But i will refer to it whenever i learn about a new problem.

As kernel and NetBSD noob i am thankful for any hints.
Some make me riddle, and some riddles i cannot solve by myself.


> >   cd /usr/src/sys/arch/i386/compile/obj/GENERIC
> >   /usr/tools/bin/nbmake

> If you just want to build a kernel and know nothing else has changed,
> that's an ok shortcut.

It got me running for experiments, for fixing a few small bugs,
and for making an API/ABI extension proposal.


I could need a tip how to juggle with two change proposals on the
same code file at the same time.
My next assault on your patience will touch a file which is part
of the pending change request kern/48808: cd9660_vfsops.c 

Both changes are not much related. So normally they could be
processed independendly.

I can of course handle two local versions of the file and its
neighbors.
But how do i present the change in a patch ?
Shall i base it on the daring assumption that kern/48808 gets
accepted as is ?
Shall i wait with the new PR until kern/48808 is decided ?
Shall i only post assessment and plan as PR and wait with the
patches ?


Have a nice day :)

Thomas