Re: Regarding the ULTRIX and OSF1 compats
Le 24/03/2019 à 00:41, Thor Lancelot Simon a écrit : On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote: On Sat, 16 Mar 2019, Maxime Villard wrote: Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper dependency in the module), because there are osf1_* calls. Some more compat mess to untangle, it seems... In all cases, it's only a few functions that are just wrappers, so it probably shouldn't be too complicated to solve. It's a total of 15 functions (I generated this list by building an alpha GENERIC kernel with COMPAT_OSF1 removed): osf1_sys_wait4 osf1_sys_mount [...] There's a funny historical reason for this -- Linux on Alpha originally used OSF/1 syscall numbering and args for its own native syscalls. No, our implementation need not actually reflect that -- but it's an interesting historical detail perhaps we should write down somewhere. Does that mean we don't need these syscalls?
Mark module tun obsolete
While looking into creating a new module for the tap pseudo-device, I noticed that for tun(4) we create both an 'if_tun' module and another 'tun' module. The latter of these seems to have no purpose other than to require the former. Perhaps there was a time when the autoload code for network drivers would not add the 'if_' prefix to the interface name (ie, autoload would only load 'tun'). But in any case that would no longer be necessary, as creating a tun interface now properly autoloads the 'if_tun' module. Therefore, I propose to remove the tun module from the distribution. Any objections? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Regarding the ULTRIX and OSF1 compats
On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote: > On Sat, 16 Mar 2019, Maxime Villard wrote: > > > Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's > > COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper > > dependency in the module), because there are osf1_* calls. Some more > > compat mess to untangle, it seems... > > > > In all cases, it's only a few functions that are just wrappers, so it > > probably shouldn't be too complicated to solve. > > It's a total of 15 functions (I generated this list by building an alpha > GENERIC kernel with COMPAT_OSF1 removed): > > osf1_sys_wait4 > osf1_sys_mount [...] There's a funny historical reason for this -- Linux on Alpha originally used OSF/1 syscall numbering and args for its own native syscalls. No, our implementation need not actually reflect that -- but it's an interesting historical detail perhaps we should write down somewhere.
Re: Regarding the ULTRIX and OSF1 compats
Le 16/03/2019 à 22:41, Paul Goyette a écrit : On Sat, 16 Mar 2019, Maxime Villard wrote: Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper dependency in the module), because there are osf1_* calls. Some more compat mess to untangle, it seems... In all cases, it's only a few functions that are just wrappers, so it probably shouldn't be too complicated to solve. It's a total of 15 functions (I generated this list by building an alpha GENERIC kernel with COMPAT_OSF1 removed): osf1_sys_wait4 osf1_sys_mount osf1_sys_set_program_attributes osf1_sys_setitimer osf1_sys_select osf1_sys_gettimeofday osf1_sys_getrusage osf1_sys_settimeofday osf1_sys_utimes osf1_sys_statfs osf1_sys_fstatfs osf1_sys_sysinfo osf1_sys_usleep_thread osf1_sys_getsysinfo osf1_sys_setsysinfo All of these are references from linux_sysent.o Here is a patch [1] that untangles the dependency. Cross-compile-tested on alpha from amd64. [1] https://m00nbsd.net/garbage/compat/alpha.diff
