Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.

> 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.
this is entirely as designed and desired.

normal kernels handle this fine within the config(5) framework.

that modules don't know how to do this properly yet is not the
existing code's problem -- that's just other of the issues that
modules have that are why they're not yet an acceptible way to
replace functionality.


.mrg.


Home | Main Index | Thread Index | Old Index