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 userl
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 inst
> 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 par
Hi,
[skipping CVS discussion aspects]
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.
In the other thread about the par
David Holland writes:
> 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
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 fi
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
/usr/src/usr.bin/fstat/iso
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 enoug
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,
>
> could be seen as such a thing. udf exposes
> the equivalent, ecma167-udf.h.
> But any interested application can jus
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
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.
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 fl
"Thomas Schmitt" 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 my ap
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
"Thomas Schmitt" 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 of januar
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
-./usr/include/isofs/
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 coul
Hi,
Taylor R Campbell:
> Just include and use uint32_t.
Ok.
In (righteously public) mount_cd9660.h
+ #include
so that any includer gets defined uint32_t for
struct iso_args {
... old members ...
+ uint32_t ssector;
};
> There are some that may be useful for userland a
Date: Tue, 13 May 2014 22:01:20 +0200
From: "Thomas Schmitt"
> 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 it does not.
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 a
"Thomas Schmitt" 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 /usr/include
Hi,
> I think Greg is right - historic accident.
They are quite up to date.
Is the mechanism known by which /usr/src/sys/fs/cd9660/*.h
gets forwarded to /usr/include/isofs/cd9660 ?
Has some script or makefile to be changed ?
> I would check with nxr.netbsd.org
93 milliseconds later:
No "iso_m
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 w
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
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
cd9660_mount.
25 matches
Mail list logo
