On Wed, May 28, 2014 at 06:22:16PM +1000, matthew green wrote:
On Wed, May 14, 2014 at 08:00:56AM +1000, matthew green wrote:
thanks for looking at this. we've gotten better since early
days with these sorts of issues, but there are still a lot of
headers that are installed for
Hi,
David Holland:
at least in the case of ufs (dunno about cd9660) the
definitions are all mixed together.
In cd9660 it is the full spectrum:
What i deem legit userland API
cd9660_mount.h : struct iso_args and its flags for mount(2).
Somewhat exotic
matthew green:
all we have to do is, like this case, simply not install them.
But i had to learn that this would break fstat(1) and pmap(1).
So i do not dare to uphold my proposal to remove the semi-private
header files.
yeah - i saw that right after i sent my post :)
if those parts can
Hi,
assessment of includers of cd9660 entrails.
The following files where found including isofs/cd9660 files
other than cd9660_mount.h, iso.h, iso_rrip.h :
/usr/src/usr.bin/fstat/isofs.c:#include
Hi,
after learning the dire truth about includers of cd9660_node.h i am
pondering about ABI compatibility measures for the necessary
change which shall handle large files.
Alternative 1:
Keep the old members and add some new members to the end of iso_node.
Let the old members represent the
On Wed, May 14, 2014 at 08:00:56AM +1000, matthew green wrote:
thanks for looking at this. we've gotten better since early
days with these sorts of issues, but there are still a lot of
headers that are installed for no good reason but no one has
had the chance/motivation to clean them up
On Tue, May 13, 2014 at 10:36:08PM +0200, Thomas Schmitt wrote:
There are some that may be useful for userland applications
to grovel through the physical format,
isofs/cd9660/iso.h could be seen as such a thing. udf exposes
the equivalent, ecma167-udf.h.
But any interested
Hi,
David Holland wrote:
In an ideal world, each filesystem would install two headers:
- one with the structures, constants, etc. needed to work with the
on-disk format; this would be used by fsck, newfs, makefs, etc.
Sounds dangerous for my cause.
Obviously my grepping was not good enough
Thomas Schmitt scdbac...@gmx.net writes:
You can certainly drop them in the Makeefile in your source tree and do
a build and see what happens.
My builds can hardly have installed or overwritten them.
cd9660_extern.h differs between /usr/include and /usr/src.
The files in /usr/include are
Hi,
get rid of OBJDIR and DESTDIR
Where would these be, if present ?
(I checked env and cd9660/Makefile.)
change a Makefile to no longer install a .h file
run a full build (from build.sh; see
pkgsrc/sysutils/etcmanage:BUILD-NetBSD for my approach)
If there is a program (in the
Thomas Schmitt scdbac...@gmx.net writes:
Hi,
get rid of OBJDIR and DESTDIR
Where would these be, if present ?
(I checked env and cd9660/Makefile.)
They would be under /usr/obj after you run build.sh.
run a full build (from build.sh; see
pkgsrc/sysutils/etcmanage:BUILD-NetBSD for
Hi,
use build.sh -u to avoid the cleandir before the
build, which is the normal method.
This reduced the run time to 6.7 seconds.
I now see that Martin Husemann already proposed this to me
a few days ago. Somehow i'm a bit overwhelmed by all the
things to learn.
you may also like the -U
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
Hi,
matthew green:
in src/distrib/sets/lists/comp you'll
find all these files you're looking at not installing now.
they'll need to be marked obsolete in here.
Guided solely by the examples in there, i make five changes in
/usr/src/distrib/sets/lists/comp/mi
like
while fixing rollovers and implementing a new mount_cd9660 option -s,
i stumble over the content of public include directory
/usr/include/isofs/cd9660
which exposes all header files from the kernel source of cd9660:
cd9660_extern.h cd9660_rrip.h iso_rrip.h
Hi,
It's probably a historical accident that so much is installed.
That's a positive opinion, regarded from the viewpoint of my goals.
In a lot of headers, there is #ifdef _KERNEL to keep kernel-private
bits from being accessed by userland.
That's semi-bad news.
My main candidate for
I think Greg is right - historic accident.
I would check with nxr.netbsd.org wether anything is referenced in
NetBSD userland. I'd guess only mount_cd9660 and corresponding rump
code paths will be affected - if that turns out correct: just make sure
that old binaries of those programs still work
Thomas Schmitt scdbac...@gmx.net writes:
I think Greg is right - historic accident.
They are quite up to date.
Sure. It's accidental that so much is exposed, but part of the build
system that they are copied.
Is the mechanism known by which /usr/src/sys/fs/cd9660/*.h
gets forwarded to
Hi,
Greg Troxel:
See src/sys/fs/cd9660/Makefile. It's specified quite straightforwardly.
... it does ?
Yes. If i correct my viewpoint from making to installing,
indicated by the path /usr/include/isofs/cd9660, then i understand
your hint. (Compliments to you and this list.)
So i would
Date: Tue, 13 May 2014 22:01:20 +0200
From: Thomas Schmitt scdbac...@gmx.net
grep on the source tree :-)
Did not bring any more findings, except 9 directory loops.
The open risk is that some application like makefs might rely
on these headers ... /usr/src/usr.sbin/makefs says
Hi,
Taylor R Campbell:
Just include sys/types.h and use uint32_t.
Ok.
In (righteously public) mount_cd9660.h
+ #include sys/types.h
so that any includer gets defined uint32_t for
struct iso_args {
... old members ...
+ uint32_t ssector;
};
There are some that may be
i'm pretty sure your plan will work fine. the things you'll
need to deal with on top of what i've seen so far are related
to the sets creation. in src/distrib/sets/lists/comp you'll
find all these files you're looking at not installing now.
they'll need to be marked obsolete in here.
you could
22 matches
Mail list logo
