Please go to https://github.com/lsof-org/lsof/pull/184 and help there! Much appreciated!

[bz]

Summary

Please help reviewing and blessing
https://github.com/lsof-org/lsof/pull/184
in order to improve lsof for FreeBSD and help long-term maintenance!

Thank you. Your help is much appreciated!

Some user space applications like lsof include both headers for
pause(3) and pause(9). That means we now have two conflicting
definitions. While previously (unitl 7ea1cac248574ed06) being a macro
this was dealt with but already caused trouble. To avoid constant
workarounds provide a way to only "hide" pause(9).

For the moment that is the lsof header guard but like NO_SYSCTL_DESCR,
NO_OBSOLETE_CODE, and some other NO_ guards, we could name this
NO_KERNEL_PAUSE and define that in lsof allowing us to remove some
other attempted workarounds in the future.

X-MFC with: 7ea1cac248574ed06c7823ffbfb9a60157240e57

[mjg]

NO_KERNEL_PAUSE is definitely the better option here. there are other header abusers (most notably zfs) and a generic way to damage control this is needed.

[kib]

Usually we do the reverse and introduce _WANT_SOMETHING when userspace really wants some kernel stuff, otherwise hidden under _KERNEL.

FREEBSD_LSOF_H is definitely a gross.

[ler]

https://github.com/lsof-org/lsof/pull/184

^^^ what do we have to do to get this acceptable?

a lot of this issue goes away.....

[mjg]

In D36608#831108, @kib wrote:

Usually we do the reverse and introduce _WANT_SOMETHING when userspace really wants some kernel stuff, otherwise hidden under _KERNEL.

FREEBSD_LSOF_H is definitely a gross.

lsof pulls in TONS of headers and it only wants some struct defs. Unfortunately making that non-bad would probably be as much effort as making lsof stop messing with /dev/kmem to begin with.

[bz]

In D36608#831108, @kib wrote:

Usually we do the reverse and introduce _WANT_SOMETHING when userspace really wants some kernel stuff, otherwise hidden under _KERNEL.

FREEBSD_LSOF_H is definitely a gross.

I agree but I needed to start with something and that was the obvious test w/o having to patch lsof further ;)

The "WANT" doesn't work as lsof and other header "abusers" usually #define KERNEL and #define _KERNEL so it needs to reverse in this case. It's further complicated in that systm.h isn't even directly included and "fixed up" right from the start but is indirectly included in the lsof case. So previous (old) workarounds fromt he "pause_sbt" fixes were already done in a way to make the life harder than easier back than.

@ler I think that would be great but is probably a larger task beyond fixing this in first place. I am adding @emaste here as well as it seems you had done so on github

[ler]

that PR has been sitting for MONTHS waiting on FreeBSD folks to bless it.

I'm about to resign from the LSOF project and put sysutils/lsof to ports@ since no one seems to care to help me (a non-kernel guy).

[imp]

sys/sys/systm.h

451

My take: hard no. Just no. It's quite simply the wrong way to do this.
Anybody that abuses _KERNEL is begging for trouble and is 100% responsible for coping with whatever trouble finds it.
I like the pull request upstream a lot better, even though it's more massive: it cleans up a lot of items and this incidentally.
Honestly, though, if someone can define NO_KERNEL_PAUSE they can #define pause kernel_pause ... #include ... #undef pause too.

[ler]

I'm happy to merge the upstream PR *IF* and only *IF* the FreeBSD kernel guys are ok with it.

I'd then cut a new upstream release.

I'm tired of the status quo.

[bz]

It almost seems everyone agrees that pulling in the github changes is the only right thing to do and that means maybe we should all go there and look at bits to get them "approved" so @ler can pull them in and the life for lsof users and maintainers will probably be a LOT easier in the future.

sys/sys/systm.h

451

If it were that easy. That really needs to happen before unistd.h is included in that lsof header file and with the "self-contained headers" systm.h pulls in quite a bit more stuff which then needs to be fixed as well..