Re: CVS commit: src/sys/arch/amd64/conf

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 04/08/2017 à 10:00, matthew green a écrit :
> Maxime Villard writes:
> > Yes, I saw that too a few days later when moving the compat_freebsd files and
> > trying to do a modload. I went "what the hell is this", but didn't do anything.
> >
> > What I could see, is that many of our compat options are at some point using
> > at least one compat_43_* function, even if they have nothing to do with 4.3BSD.
> >
> > It appears that people just chose to use them, because they were convenient,
> > instead of re-writing them on purpose. The assumption was that the compat_43
> > functions would always be there; that's obviously a wrong assumption.
> >
> > As a quick fix, I can revert my change. But that does not fix this mess; we
> > would have to either rename compat_43_* to compat_common_* and compile them by
> > default (ie, without depending on an #ifdef COMPAT_43), or we would have to
> > implement the functions in all of the compat options with proper names (eg
> > compat_43_sys_lseek -> freebsd_sys_lseek).
>
> please revert your change (for now?).  thanks.

Alright, I'll do that for now.

> > Frankly, this is a huge mess.
>
> i don't agree.
>
> the setup comes from before modules and it allows code sharing
> because the old 43 version matches other systems. so there's
> a single implementation of this code for a large number of
> consumers, and the name of it describes where it comes from.

Yes, but the fact that the availability of the compat_43_* functions depends
on #ifdef COMPAT_43, while they are just common functions used in a lot of
places, is wrong. And it has nothing to do with the modules, it was already
wrong before they were introduced (even if it used to be harmless).

As a third (and simpler) solution, we could make sure that these functions are
compiled regardless of COMPAT_43, without renaming them.

Maxime