Re: CVS commit: src/sys/compat/netbsd32
Oops, thanks for quick fix, and it seems that I need a cup of coffee... Thanks, rin On 2023/07/29 22:57, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Sat Jul 29 13:57:28 UTC 2023 Modified Files: src/sys/compat/netbsd32: netbsd32_compat_80.c netbsd32_compat_90.c Log Message: Don't skip compat_netbsd32_90 in the dependency chain. To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/sys/compat/netbsd32/netbsd32_compat_80.c cvs rdiff -u -r1.1 -r1.2 src/sys/compat/netbsd32/netbsd32_compat_90.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/compat/netbsd32
On 2023/07/29 22:13, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Sat Jul 29 13:13:50 UTC 2023 Modified Files: src/sys/compat/netbsd32: netbsd32_compat_50.c Log Message: Now, netbsd32_compat_50 module requires netbsd32_compat_100. Thanks pgoyette@ for hints. Hmm, file name is netbsd32_compat_x.c but module name is compat_netbsd32_x. Diff was correct :) Thanks, rin
Re: CVS commit: src/sys/compat/netbsd32
Hi Simon On 17/01/2021 11:26, Simon Burge wrote: On 15/01/2021 07:15, matthew green wrote: Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. No, it's currently unique to NetBSD. Other BSD's just don't have the infrastructure in their network for it either. I'll note that on a 64-bit platform it's 64 bits though so these do gains something. The value is similar to struct if_data counters really, so maybe it should be a uint64_t if you really want to change it. I would then argue that it might be better then to version it proper and move it out of compat32. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. I would just like arp to work without error. My personal preference would be to keep the same API and add compat. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Looks great! Also looks the same as what I did but couldn't get to work. Maybe I missed the netbsd32 on the long. Roy
Re: CVS commit: src/sys/compat/netbsd32
Hi Roy, Roy Marples wrote: > On 15/01/2021 07:15, matthew green wrote: > >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD > >> and is the same struct on all BSD. While bringing the same functionality to > >> IPv4, I elected to keep the same struct just to have the same API, warts > >> and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. > > [ .. ] > >> > >> That breaks API/ABI though yes? As such it would require stuff in compat > >> anyway, but leaving it as it just needs n32 compat gunk instead which is > >> less impactful on other systems. > > > > in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can > > choose to break them in -current. there's a slight problem that -current > > has > > a minor flag day here, but it's not the compat issue you seem to think. > > CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Sorry, I only checked the history of in_nbrinfo and just assumed that in6_nbrinfo was of a similar vintage. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Cheers, Simon.
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 02:43, Simon Burge wrote: I'll test a bit more I can't actually test as my ERLite won't boot anymore. Console light is green, cu says I'm connected but I get nothing out of it. With cat5 cables plugged in the ports they flash green and then stick on amber. I'm guessing this is non recoverable :( If it is recoverable somehow I can put NetBSD back on it as I have a shiny new USG in it's place. Roy
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 07:15, matthew green wrote: Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. [ .. ] That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5 Roy
re: CVS commit: src/sys/compat/netbsd32
> Oh, I quite agree. > However, in6_nbrinfo predates my involvement with NetBSD and is the same > struct > on all BSD. While bringing the same functionality to IPv4, I elected to keep > the > same struct just to have the same API, warts and all. I like consistency. [ .. ] > > That breaks API/ABI though yes? > As such it would require stuff in compat anyway, but leaving it as it just > needs > n32 compat gunk instead which is less impactful on other systems. in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can choose to break them in -current. there's a slight problem that -current has a minor flag day here, but it's not the compat issue you seem to think. with simon's proposed patch, the API doesn't change, so there no source compat issue to worry about either. this _only_ breaks -current in the last 4 months or so. i think we should do this, rather than add additional compat. we're allowed (and should!) fix -current issues like this. .mrg.
Re: CVS commit: src/sys/compat/netbsd32
On 15/01/2021 02:43, Simon Burge wrote: Hi Roy, Roy Marples wrote: On 14/01/2021 11:03, Simon Burge wrote: Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). As they share a similar structure, you solve one you likely solve the other. I can assume you have working IPv4 ;) In general where we can define the structure that are passed in an interface, regardless if it's a ioctl or sysctl or whatever, we should try to design the structure so that it's the same regardless of if it's built with 32-bit or 64-bit userlands. Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD and is the same struct on all BSD. While bringing the same functionality to IPv4, I elected to keep the same struct just to have the same API, warts and all. I like consistency. The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in the structure, so this has different sizes depending on your native long size. I _think_ this is the is value out of the la_asked member of struct llentry which is a uint16_t so we can just make it an int the your structures will align nicely. In both cases the ifname name is 16 bytes. For in_nbrinfo in_addr is effectively an int so we have just four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes so aligns nicely, then a couple more ints after that. If "asked" is from struct llentry then the attached patch should work without requiring any compat32 support. If you're happy with this, I'll test a bit more then commit. That breaks API/ABI though yes? As such it would require stuff in compat anyway, but leaving it as it just needs n32 compat gunk instead which is less impactful on other systems. Roy
Re: CVS commit: src/sys/compat/netbsd32
Hi Roy,
Roy Marples wrote:
> On 14/01/2021 11:03, Simon Burge wrote:
> > Sure, I will have a look. Anything IPv6 related I might need a helping
> > hand to get a test case though :).
>
> As they share a similar structure, you solve one you likely solve the other.
> I can assume you have working IPv4 ;)
In general where we can define the structure that are passed in an
interface, regardless if it's a ioctl or sysctl or whatever, we should
try to design the structure so that it's the same regardless of if it's
built with 32-bit or 64-bit userlands. This is hard where you have
pointers, both otherwise is usually possible with a bit of planning.
You especially need to watch out for long which is a different size on
32-bit/64-bit userlands and also for int64_t which can align differently
depending on the architecture. If you can do a printf of the struct
size with a variety of arches and they're all the same then good! amd64,
i386, mips64 (n32), sparc would probably cover the range of cases to
test on (a compile test will do if you look at the generated code for
what is passed to printf). The general rule is if we can avoid touching
compat/netbsd32 then life is easier!
The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in
the structure, so this has different sizes depending on your native long
size.
I _think_ this is the is value out of the la_asked member of struct
llentry which is a uint16_t so we can just make it an int the your
structures will align nicely. In both cases the ifname name is 16
bytes. For in_nbrinfo in_addr is effectively an int so we have just
four ints after the ifname. For in6_nbrinfo the in6_addr is 128 bytes
so aligns nicely, then a couple more ints after that.
If "asked" is from struct llentry then the attached patch should work
without requiring any compat32 support. If you're happy with this, I'll
test a bit more then commit.
Cheers,
Simon.
Index: netinet/in_var.h
===
RCS file: /cvsroot/src/sys/netinet/in_var.h,v
retrieving revision 1.98
diff -d -p -u -r1.98 in_var.h
--- netinet/in_var.h11 Sep 2020 15:22:12 - 1.98
+++ netinet/in_var.h15 Jan 2021 02:18:01 -
@@ -118,7 +118,7 @@ struct in_ifaddr {
struct in_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in_addr addr;/* IPv4 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
};
Index: netinet6/nd6.h
===
RCS file: /cvsroot/src/sys/netinet6/nd6.h,v
retrieving revision 1.91
diff -d -p -u -r1.91 nd6.h
--- netinet6/nd6.h 11 Sep 2020 15:03:33 - 1.91
+++ netinet6/nd6.h 15 Jan 2021 02:18:01 -
@@ -83,7 +83,7 @@ struct nd_kifinfo {
struct in6_nbrinfo {
char ifname[IFNAMSIZ]; /* if name, e.g. "en0" */
struct in6_addr addr; /* IPv6 address of the neighbor */
- longasked; /* number of queries already sent for this addr
*/
+ int asked; /* number of queries already sent for this addr
*/
int isrouter; /* if it acts as a router */
int state; /* reachability state */
int expire; /* lifetime for NDP state transition */
Re: CVS commit: src/sys/compat/netbsd32
On 14/01/2021 11:03, Simon Burge wrote: Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). As they share a similar structure, you solve one you likely solve the other. I can assume you have working IPv4 ;) Roy
Re: CVS commit: src/sys/compat/netbsd32
Roy Marples wrote: > On 14/01/2021 08:00, Simon Burge wrote: > > Module Name:src > > Committed By: simonb > > Date: Thu Jan 14 08:00:45 UTC 2021 > > > > Modified Files: > > src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h > > > > Log Message: > > Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now. > > XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. > > Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 > (ndp -a) please? > > I could never get that working. Sure, I will have a look. Anything IPv6 related I might need a helping hand to get a test case though :). Cheers, Simon.
Re: CVS commit: src/sys/compat/netbsd32
On 14/01/2021 08:00, Simon Burge wrote: Module Name:src Committed By: simonb Date: Thu Jan 14 08:00:45 UTC 2021 Modified Files: src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h Log Message: Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now. XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled. Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 (ndp -a) please? I could never get that working. Thanks Roy
Re: CVS commit: src/sys/compat/netbsd32
On Mon, 9 Mar 2020, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Mon Mar 9 01:06:34 UTC 2020 Modified Files: src/sys/compat/netbsd32: netbsd32_mod.c Log Message: If a syscall requires a module to be autoloaded, the initial invocation of that syscall will return ERESTART. For amd64's netbsd32_syscall() that means we need to back up the PC saved in the trap frame so we can re-issue the syscall instruction. For "normal" syscall traps, we saved the instruction length in the trap frame, but this was missing for the oosyscall/lcall path. Since the PC was not backed up, the kernel-only value ERESTART was returned to userland, causing all sort of grief for old compat_netbsd32 executables! While here, I also added some comments on some recent #endif to better identify their associated #if - no functional change intended for this. XXX Pullup-9 To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 src/sys/compat/netbsd32/netbsd32_mod.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5e6596db22973983836595! ++--+---+ | 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: CVS commit: src/sys/compat/netbsd32
On 2019/11/04 20:20, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Mon Nov 4 11:20:22 UTC 2019 Modified Files: src/sys/compat/netbsd32: syscalls.master Log Message: For netbsd32_readlinkat(2), bufsize is netbsd_size_t, not size_t. Since bufsize is the last argument, this affects only LP64EB. XXX pullup to netbsd-9, -8, and -7 To generate a diff of this commit: cvs rdiff -u -r1.128 -r1.129 src/sys/compat/netbsd32/syscalls.master Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. s/netbsd_size_t/netbsd32_size_t/ in the commit log.
Re: CVS commit: src/sys/compat/netbsd32
Thanks for the quick review! The errors below should be all fixed. christos > On Aug 20, 2019, at 3:18 PM, Maxime Villard wrote: > > 1) In compat_drm_agp_info(), seems like it should be info64to32. > > 2) In compat_drm_getstats(), the assignments in the loop are inverted, it's > st32 which should be set to the values of st64, not the other way around. > > 3) In compat_drm_dma(), again inverted 32<->64, and there is no copyout (?). > > 4) In compat_drm_agp_enable(), m64 is uninitialized, everything is wrong in > this function it seems.
Re: CVS commit: src/sys/compat/netbsd32
Le 20/08/2019 à 11:32, Christos Zoulas a écrit : Module Name:src Committed By: christos Date: Tue Aug 20 09:32:21 UTC 2019 Modified Files: src/sys/compat/netbsd32: files.netbsd32 netbsd32_ioctl.c netbsd32_ioctl.h Added Files: src/sys/compat/netbsd32: netbsd32_drm.c Log Message: compat32 drm ioctl support from Surya Shankar at GSoC 2019 To generate a diff of this commit: cvs rdiff -u -r1.45 -r1.46 src/sys/compat/netbsd32/files.netbsd32 cvs rdiff -u -r0 -r1.1 src/sys/compat/netbsd32/netbsd32_drm.c cvs rdiff -u -r1.103 -r1.104 src/sys/compat/netbsd32/netbsd32_ioctl.c cvs rdiff -u -r1.67 -r1.68 src/sys/compat/netbsd32/netbsd32_ioctl.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Pieces of code like this one which touch kernel entry points should go through proper reviewing because they can cause immense trouble. They should not be committed and enabled by default blindly like you just did. Here are my remarks: 1) In compat_drm_agp_info(), seems like it should be info64to32. 2) In compat_drm_getstats(), the assignments in the loop are inverted, it's st32 which should be set to the values of st64, not the other way around. 3) In compat_drm_dma(), again inverted 32<->64, and there is no copyout (?). 4) In compat_drm_agp_enable(), m64 is uninitialized, everything is wrong in this function it seems. Etc, that's just after a quick glance. I will disable this code until it receives proper review.
re: CVS commit: src/sys/compat/netbsd32
"Paul Goyette" writes: > Module Name: src > Committed By: pgoyette > Date: Wed Jan 30 02:00:02 UTC 2019 > > Modified Files: > src/sys/compat/netbsd32: netbsd32_compat_80.c > > Log Message: > Remove #ifdef COMPAT_80 > > The file will only be selected if "options COMPAT_80" is defined in > the config file. The COMPAT_80 macro is defined only if the option > is explicitly defined, and not if it is implicitly defined due to > inclusion of lesser-version COMPATs. actually, the problem wasn't that it's not defined (it better be!), but that the opt_foo.h wasn't / isn't included. removing the #ifdef check is the right answer, but i wanted to be sure you understood _why_ this was failing before. it still may be useful to include the opt_foo.h file -- depends on if header files may depend on it or not (and i tend to believe they should include them directly), but this file itself does not. thanks. .mrg.
re: CVS commit: src/sys/compat/netbsd32
On Dec 7, 7:34am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/compat/netbsd32 | can they make 32 bit trace records instead? if not, why not? Because every other syscall is making 64 bit records, so ktrace.out file is only parseable/readable by the 64 bit ktrace. Putting a 32 bit signal record inside a 64 bit record file does not make any sense (try it). When/if we fix 32 bit processes to emit 32 bit records then we can switch back. christos
re: CVS commit: src/sys/compat/netbsd32
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Wed Dec 6 19:15:27 UTC 2017 > > Modified Files: > src/sys/compat/netbsd32: netbsd32_netbsd.c netbsd32_signal.c > > Log Message: > disable 32 bit signal ktrace records; 32 bit traced process produce 64 bit > trace records, the only record that we can't parse is that one :-) > XXX: pullup-8 can they make 32 bit trace records instead? if not, why not? thanks. .mrg.
Re: CVS commit: src/sys/compat/netbsd32
On 2016/11/20 21:18, Michael van Elst wrote: Looks fine to me. Committed. Thank you for your review! Rin
Re: CVS commit: src/sys/compat/netbsd32
On Thu, Nov 17, 2016 at 09:46:09PM +0900, Rin Okuyama wrote: > On 2016/11/16 18:33, Michael van Elst wrote: > >So I suggest to make the compat32 code handle CLOCK_NTP_ADJTIME even > >when compiled with !NTP but just return ENOTTY. > > > >N.B. clockctlioctl returns EINVAL for unrecognized ioctl commands, > >it should also return ENOTTY. > > I wrote a patch. Besides your suggestions, I protected NTP stuff in > compat50 codes by NTP macro. Is it ok with you? Looks fine to me. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: CVS commit: src/sys/compat/netbsd32
On 2016/11/16 18:33, Michael van Elst wrote:
So I suggest to make the compat32 code handle CLOCK_NTP_ADJTIME even
when compiled with !NTP but just return ENOTTY.
N.B. clockctlioctl returns EINVAL for unrecognized ioctl commands,
it should also return ENOTTY.
I wrote a patch. Besides your suggestions, I protected NTP stuff in
compat50 codes by NTP macro. Is it ok with you?
Thanks,
Rin
--- src/sys/compat/netbsd32/netbsd32_ioctl.c.orig 2016-11-17
21:10:05.784020949 +0900
+++ src/sys/compat/netbsd32/netbsd32_ioctl.c2016-11-17 21:17:42.250121516
+0900
@@ -1324,8 +1324,8 @@
case CLOCKCTL_CLOCK_SETTIME32:
IOCTL_STRUCT_CONV_TO(CLOCKCTL_CLOCK_SETTIME,
clockctl_clock_settime);
-#ifdef NTP
case CLOCKCTL_NTP_ADJTIME32:
+#ifdef NTP
{
size = IOCPARM_LEN(CLOCKCTL_NTP_ADJTIME);
if (size > sizeof(stkbuf))
@@ -1346,7 +1346,10 @@
break;
}
-#endif
+#else
+ error = ENOTTY;
+ break;
+#endif /* NTP */
case KIOCGSYMBOL32:
IOCTL_STRUCT_CONV_TO(KIOCGSYMBOL, ksyms_gsymbol);
--- src/sys/dev/clockctl.c.orig 2016-11-17 21:17:52.116138355 +0900
+++ src/sys/dev/clockctl.c 2016-11-17 21:25:27.068388985 +0900
@@ -266,7 +266,7 @@
#ifdef COMPAT_50
error = compat50_clockctlioctl(dev, cmd, data, flags, l);
#else
- error = EINVAL;
+ error = ENOTTY;
#endif
}
@@ -328,13 +328,16 @@
error = clock_settime1(l->l_proc, args->clock_id, , true);
break;
}
- case CLOCKCTL_ONTP_ADJTIME:
+#ifdef NTP
+ case CLOCKCTL_ONTP_ADJTIME: {
/* The ioctl number changed but the data did not change. */
error = (cd->d_ioctl)(dev, CLOCKCTL_NTP_ADJTIME,
data, flags, l);
break;
+ }
+#endif
default:
- error = EINVAL;
+ error = ENOTTY;
}
return (error);
Re: CVS commit: src/sys/compat/netbsd32
On 2016/11/16 18:33, Michael van Elst wrote: There is a slight twist. If NTP isn't defined, the code will call the standard (64bit) ioctl handler with the assumption that the arg uses the same layout in 64bit and 32bit mode. If the ioctl handler is builtin, it won't understand the ioctl either and everything is fine. But if it is a loaded module, it might be compiled with different NTP option and so the wrong routine is called. Fortunately that's just theoretical because the module can't be loaded when compiled differently (because it references ntp_adjtime). But that is a different issue and might be solved in the future. So I suggest to make the compat32 code handle CLOCK_NTP_ADJTIME even when compiled with !NTP but just return ENOTTY. N.B. clockctlioctl returns EINVAL for unrecognized ioctl commands, it should also return ENOTTY. Thank you for pointing out the possible failure. Your suggestion sounds good to me. Thanks, Rin
Re: CVS commit: src/sys/compat/netbsd32
On Tue, Nov 15, 2016 at 07:44:52PM +0900, Rin Okuyama wrote: > On 2016/11/15 19:26, Martin Husemann wrote: > >On Tue, Nov 15, 2016 at 07:23:09PM +0900, Rin Okuyama wrote: > >>This results in build failure for most ARM environments: > >> > >> http://releng.netbsd.org/builds/HEAD/201611140950Z/ > >> > >>I think that NTP stuff should be protected by "#ifdef NTP". > >>Can I commit the attached patch? > > > >Sounds good, but don't you need to add #include "opt_ntp.h" to > >netbsd32_ioctl.c ? > > Thank you so much! I added this. Otherwise, NTP kernel gets > broken this time... There is a slight twist. If NTP isn't defined, the code will call the standard (64bit) ioctl handler with the assumption that the arg uses the same layout in 64bit and 32bit mode. If the ioctl handler is builtin, it won't understand the ioctl either and everything is fine. But if it is a loaded module, it might be compiled with different NTP option and so the wrong routine is called. Fortunately that's just theoretical because the module can't be loaded when compiled differently (because it references ntp_adjtime). But that is a different issue and might be solved in the future. So I suggest to make the compat32 code handle CLOCK_NTP_ADJTIME even when compiled with !NTP but just return ENOTTY. N.B. clockctlioctl returns EINVAL for unrecognized ioctl commands, it should also return ENOTTY. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
re: CVS commit: src/sys/compat/netbsd32
> > i didn't look closely, but note that netbsd 5.0 had different > > time_t -- it was only 32 bits. > > > > please check the compat50 and earlier code works fine with this. > > I've checked that i386 binaries from 5.2.2 work on amd64. perfect, thanks! .mrg.
Re: CVS commit: src/sys/compat/netbsd32
Hi,
On 2016/11/13 1:06, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Nov 12 16:06:04 UTC 2016
Modified Files:
src/sys/compat/netbsd32: netbsd32_ioctl.c netbsd32_ioctl.h
Log Message:
Fix netbsd32 emulation for clockctl_ntp_adjtime.
The ioctl args reference a timex structure that needs to be
transformed to 64bit layout and back.
The 32bit ioctl definition was wrong for mips, as register_t is 64bit
for N32 abi.
After this commit, non-NTP kernel fails to build:
netbsd32_ioctl.o: In function `netbsd32_do_clockctl_ntp_adjtime':
xxx/../../../../compat/netbsd32/netbsd32_ioctl.c:938: undefined reference to
`ntp_adjtime1'
xxx/../../../../compat/netbsd32/netbsd32_ioctl.c:943: undefined reference to
`ntp_timestatus'
*** [netbsd] Error code 1
This results in build failure for most ARM environments:
http://releng.netbsd.org/builds/HEAD/201611140950Z/
I think that NTP stuff should be protected by "#ifdef NTP".
Can I commit the attached patch?
Thanks,
Rin
===
--- src/sys/compat/netbsd32/netbsd32_ioctl.c.orig 2016-11-15
18:41:41.050970773 +0900
+++ src/sys/compat/netbsd32/netbsd32_ioctl.c2016-11-15 19:06:19.965189392
+0900
@@ -422,6 +422,7 @@
p->tp = NETBSD32PTR64(s32p->tp);
}
+#ifdef NTP
static inline void
netbsd32_to_clockctl_ntp_adjtime(
const struct netbsd32_clockctl_ntp_adjtime *s32p,
@@ -432,6 +433,7 @@
p->tp = NETBSD32PTR64(s32p->tp);
p->retval = s32p->retval;
}
+#endif
static inline void
netbsd32_to_ksyms_gsymbol(
@@ -842,6 +844,7 @@
NETBSD32PTR32(s32p->tp, p->tp);
}
+#ifdef NTP
static inline void
netbsd32_from_clockctl_ntp_adjtime(
const struct clockctl_ntp_adjtime *p,
@@ -852,6 +855,7 @@
NETBSD32PTR32(s32p->tp, p->tp);
s32p->retval = p->retval;
}
+#endif
static inline void
netbsd32_from_ksyms_gsymbol(
@@ -922,6 +926,7 @@
NETBSD32PTR32(s32p->locators, p->locators);
}
+#ifdef NTP
static int
netbsd32_do_clockctl_ntp_adjtime(struct clockctl_ntp_adjtime *args)
{
@@ -944,6 +949,7 @@
return error;
}
+#endif
/*
* main ioctl syscall.
@@ -1314,6 +1320,7 @@
case CLOCKCTL_CLOCK_SETTIME32:
IOCTL_STRUCT_CONV_TO(CLOCKCTL_CLOCK_SETTIME,
clockctl_clock_settime);
+#ifdef NTP
case CLOCKCTL_NTP_ADJTIME32:
{
size = IOCPARM_LEN(CLOCKCTL_NTP_ADJTIME);
@@ -1335,6 +1342,7 @@
break;
}
+#endif
case KIOCGSYMBOL32:
IOCTL_STRUCT_CONV_TO(KIOCGSYMBOL, ksyms_gsymbol);
Re: CVS commit: src/sys/compat/netbsd32
On 2016/11/15 19:26, Martin Husemann wrote: On Tue, Nov 15, 2016 at 07:23:09PM +0900, Rin Okuyama wrote: This results in build failure for most ARM environments: http://releng.netbsd.org/builds/HEAD/201611140950Z/ I think that NTP stuff should be protected by "#ifdef NTP". Can I commit the attached patch? Sounds good, but don't you need to add #include "opt_ntp.h" to netbsd32_ioctl.c ? Thank you so much! I added this. Otherwise, NTP kernel gets broken this time... Thanks, Rin
Re: CVS commit: src/sys/compat/netbsd32
On Tue, Nov 15, 2016 at 07:23:09PM +0900, Rin Okuyama wrote: > This results in build failure for most ARM environments: > > http://releng.netbsd.org/builds/HEAD/201611140950Z/ > > I think that NTP stuff should be protected by "#ifdef NTP". > Can I commit the attached patch? Sounds good, but don't you need to add #include "opt_ntp.h" to netbsd32_ioctl.c ? Martin
Re: CVS commit: src/sys/compat/netbsd32
On 2016/11/15 8:16, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Sun Nov 13 13:59:45 UTC 2016
Modified Files:
src/sys/compat/netbsd32: netbsd32_conv.h
Log Message:
correct wrong casting. some are considered harmless, but
- tv_sec in netbsd32_timeval is netbsd32_time_t (aka netbsd32_int64_t)
rather than time_t (int64_t)
- tv_sec in netbsd32_timespec is netbsd32_time_t rather than
netbsd32_long (y2038 problem)
approved by martin
i didn't look closely, but note that netbsd 5.0 had different
time_t -- it was only 32 bits.
please check the compat50 and earlier code works fine with this.
I've checked that i386 binaries from 5.2.2 work on amd64. The point is
that netbsd32_time{val,spec}50 are converted into/from time{val,spec}.
Not time{val,spec}50. Function names netbsd32_{to,from}_time{val,spec}50
may be misleading, although they conform to the naming rules...
Thanks,
Rin
re: CVS commit: src/sys/compat/netbsd32
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Sun Nov 13 13:59:45 UTC 2016 > > Modified Files: > src/sys/compat/netbsd32: netbsd32_conv.h > > Log Message: > correct wrong casting. some are considered harmless, but > - tv_sec in netbsd32_timeval is netbsd32_time_t (aka netbsd32_int64_t) > rather than time_t (int64_t) > - tv_sec in netbsd32_timespec is netbsd32_time_t rather than > netbsd32_long (y2038 problem) > approved by martin i didn't look closely, but note that netbsd 5.0 had different time_t -- it was only 32 bits. please check the compat50 and earlier code works fine with this. thanks. .mrg.
re: CVS commit: src/sys/compat/netbsd32
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Sun Nov 13 13:52:41 UTC 2016 > > Modified Files: > src/sys/compat/netbsd32: netbsd32.h > > Log Message: > tv_usec in netbsd32_timeval is suseconds_t (aka int32_t) rather than > netbsd32_long (considered harmless) > > approved by martin heh - this changed in 2009, when timeval was two longs. well spotted. :-) .mrg.
re: CVS commit: src/sys/compat/netbsd32
David A. Holland writes: Module Name: src Committed By: dholland Date: Tue Jun 23 04:44:08 UTC 2015 Modified Files: src/sys/compat/netbsd32: syscalls.master Log Message: Don't reference netbsd32_nfssvc unless NFSSERVER is defined. Fixes PR 49994. thanks.
Re: CVS commit: src/sys/compat/netbsd32
On Tue, Jun 23, 2015 at 06:23:36PM +1000, matthew green wrote: Log Message: Don't reference netbsd32_nfssvc unless NFSSERVER is defined. Fixes PR 49994. thanks. *bow* -- David A. Holland dholl...@netbsd.org
re: CVS commit: src/sys/compat/netbsd32
Matt Thomas writes: Module Name: src Committed By: matt Date: Fri May 15 07:52:51 UTC 2015 Modified Files: src/sys/compat/netbsd32: netbsd32_lwp.c Log Message: In lwp_ctl, convert ptr to 32 bits before copyout. i wonder if we should KASSERT() that the vaddr_t fits in 32 bits? or ... fits in VM_*ADDRESS_USER? .mrg.
Re: CVS commit: src/sys/compat/netbsd32
On Fri, Jun 13, 2014 at 10:42:26AM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Fri Jun 13 10:42:26 UTC 2014 Modified Files: src/sys/compat/netbsd32: netbsd32_sysctl.c Log Message: Rename stack gap arguments. stack gap ? that was expunged years ago... David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/compat/netbsd32
On Tue, 4 Jan 2011, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 4 10:59:29 UTC 2011 Modified Files: src/sys/compat/netbsd32: files.netbsd32 netbsd32_sa.c Log Message: Make the SA support as optional as is possible. This commit appears to have broken the build, at least on port-amd64: #create compat_netbsd32/netbsd32_sa.d CC=/test-bed/tools/bin/x86_64--netbsd-gcc /test-bed/tools/bin/nbmkdep -f netbsd32_sa.d -- -I/test-bed/src/common/include -DSYSVSHM -DSYSVSEM -DSYSVMSG -DCOMPAT_NETBSD32 -DEXEC_ELF32 -DEXEC_ELF64 -DEXEC_AOUT -DP1003_1B_SEMAPHORE -DCOREDUMP -I/test-bed/src/common/include -nostdinc -I. -I/test-bed/src/sys/modules/compat_netbsd32 -isystem /test-bed/src/sys -isystem /test-bed/src/sys/arch -isystem /test-bed/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -std=gnu99 /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:37:31: error: opt_compat_netbsd.h: No such file or directory /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:38:20: error: opt_sa.h: No such file or directory nbmkdep: compile failed. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/sys/compat/netbsd32
The following patch seems to take care of things, at least on my amd64 machine. I'm not sure if this is the correct fix, so I will let someone else handle the commit! Index: netbsd32_sa.c === RCS file: /cvsroot/src/sys/compat/netbsd32/netbsd32_sa.c,v retrieving revision 1.12 diff -u -p -r1.12 netbsd32_sa.c --- netbsd32_sa.c 4 Jan 2011 10:59:28 - 1.12 +++ netbsd32_sa.c 4 Jan 2011 13:56:08 - @@ -34,8 +34,11 @@ #include sys/cdefs.h __KERNEL_RCSID(0, $NetBSD: netbsd32_sa.c,v 1.12 2011/01/04 10:59:28 matt Exp $); + +#if defined(_KERNEL_OPT) #include opt_compat_netbsd.h #include opt_sa.h +#endif #include sys/types.h #include sys/param.h On Tue, 4 Jan 2011, Paul Goyette wrote: On Tue, 4 Jan 2011, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 4 10:59:29 UTC 2011 Modified Files: src/sys/compat/netbsd32: files.netbsd32 netbsd32_sa.c Log Message: Make the SA support as optional as is possible. This commit appears to have broken the build, at least on port-amd64: #create compat_netbsd32/netbsd32_sa.d CC=/test-bed/tools/bin/x86_64--netbsd-gcc /test-bed/tools/bin/nbmkdep -f netbsd32_sa.d -- -I/test-bed/src/common/include -DSYSVSHM -DSYSVSEM -DSYSVMSG -DCOMPAT_NETBSD32 -DEXEC_ELF32 -DEXEC_ELF64 -DEXEC_AOUT -DP1003_1B_SEMAPHORE -DCOREDUMP -I/test-bed/src/common/include -nostdinc -I. -I/test-bed/src/sys/modules/compat_netbsd32 -isystem /test-bed/src/sys -isystem /test-bed/src/sys/arch -isystem /test-bed/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -std=gnu99 /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:37:31: error: opt_compat_netbsd.h: No such file or directory /test-bed/src/sys/compat/netbsd32/netbsd32_sa.c:38:20: error: opt_sa.h: No such file or directory nbmkdep: compile failed. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | - - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
re: CVS commit: src/sys/compat/netbsd32
Module Name: src
Committed By:njoly
Date:Thu Dec 10 14:58:28 UTC 2009
Modified Files:
src/sys/compat/netbsd32: netbsd32_ioctl.c
Log Message:
Make netbsd32_from_{ifreq,oifreq}() copy the whole structure, not only
the interface name. Finally fix my own PR/39424.
ok by christos.
this uses the size of the non-compat version to copy, which leads to
it copying beyond the allocated space doesn't it? ie, it should be:
memcpy(s32p, p, sizeof *s32p);
shouldn't it?
.mrg.
