search for: undef'd

Displaying 13 results from an estimated 13 matches for "undef'd".

Did you mean: undef's
2016 Jan 04
4
[PATCH v2 17/32] arm: define __smp_xxx
...e they're prefixed with __* > > unfortunately doesn't stop anyone from using it (been there with > > other arch stuff before.) > > > > I wonder whether we should consider making the smp memory barriers > > inline functions, so these __smp_xxx() variants can be undef'd > > afterwards, thereby preventing drivers getting their hands on these > > new macros? > > That'd be tricky to do cleanly since asm-generic depends on > ifndef to add generic variants where needed. > > But it would be possible to add a checkpatch test for thi...
2016 Jan 04
4
[PATCH v2 17/32] arm: define __smp_xxx
...e they're prefixed with __* > > unfortunately doesn't stop anyone from using it (been there with > > other arch stuff before.) > > > > I wonder whether we should consider making the smp memory barriers > > inline functions, so these __smp_xxx() variants can be undef'd > > afterwards, thereby preventing drivers getting their hands on these > > new macros? > > That'd be tricky to do cleanly since asm-generic depends on > ifndef to add generic variants where needed. > > But it would be possible to add a checkpatch test for thi...
2016 Jan 04
1
[PATCH v2 17/32] arm: define __smp_xxx
...; unfortunately doesn't stop anyone from using it (been there with > > > > other arch stuff before.) > > > > > > > > I wonder whether we should consider making the smp memory barriers > > > > inline functions, so these __smp_xxx() variants can be undef'd > > > > afterwards, thereby preventing drivers getting their hands on these > > > > new macros? > > > > > > That'd be tricky to do cleanly since asm-generic depends on > > > ifndef to add generic variants where needed. > > > &g...
2016 Jan 04
1
[PATCH v2 17/32] arm: define __smp_xxx
...; unfortunately doesn't stop anyone from using it (been there with > > > > other arch stuff before.) > > > > > > > > I wonder whether we should consider making the smp memory barriers > > > > inline functions, so these __smp_xxx() variants can be undef'd > > > > afterwards, thereby preventing drivers getting their hands on these > > > > new macros? > > > > > > That'd be tricky to do cleanly since asm-generic depends on > > > ifndef to add generic variants where needed. > > > &g...
2016 Jan 02
2
[PATCH v2 17/32] arm: define __smp_xxx
...to a "new" set of barriers - just because they're prefixed with __* unfortunately doesn't stop anyone from using it (been there with other arch stuff before.) I wonder whether we should consider making the smp memory barriers inline functions, so these __smp_xxx() variants can be undef'd afterwards, thereby preventing drivers getting their hands on these new macros? -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
2016 Jan 02
2
[PATCH v2 17/32] arm: define __smp_xxx
...to a "new" set of barriers - just because they're prefixed with __* unfortunately doesn't stop anyone from using it (been there with other arch stuff before.) I wonder whether we should consider making the smp memory barriers inline functions, so these __smp_xxx() variants can be undef'd afterwards, thereby preventing drivers getting their hands on these new macros? -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
2018 Jun 08
3
vanilla build of 7.7p1 release on linux/4.17 fails with gcc8 @ "/usr/bin/ld: unrecognized option '-Wl,-z,retpolineplt'"
One difference I notice is that in your failing example you are invoking /usr/bin/ld directly to link: /usr/bin/ld -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o -L. -Lopenbsd-compat/ -Wl,-z,retpolineplt -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie -lssh -lopenbsd-compat -lutil -lz -lcrypt -lresolv whereas my example is
2018 Jun 08
4
vanilla build of 7.7p1 release on linux/4.17 fails with gcc8 @ "/usr/bin/ld: unrecognized option '-Wl,-z,retpolineplt'"
...18 at 10:52, PGNet Dev <pgnet.dev at gmail.com> wrote: [...] > So, there's a problem for OpenSSH build with spec'ing LD=/usr/bin/ld ? in this particular case, apparently yes. not generally, though. [...] > What's *intended* re: openssh? Support for LD=ld or only =gcc, or undef'd ? Well the intent is you should be able to set CC and LD to whatever you want as long as they work. In this case, the OSSH_CHECK_LDFLAG_LINK test invokes autoconf's AC_LINK_IFELSE with uses CC not LD. I'm not sure what to do about it yet though. -- Darren Tucker (dtucker at dtuck...
2003 Dec 05
6
ssh not resolving host names on HP-UX 11i
Actually it really never was answered, but here's how I fixed (worked around) it. At first I thought installing patch PHNE_27796 (libnss_dns DNS backend patch) had fixed it. It didn't. It just flip-flopped the problem. Prior to installing that patch, ssh would never go to DNS no matter what was in nsswitch.conf. It appeared to only look in /etc/hosts. After installing the patch, ssh
2016 Jan 03
0
[PATCH v2 17/32] arm: define __smp_xxx
...of barriers - just because they're prefixed with __* > unfortunately doesn't stop anyone from using it (been there with > other arch stuff before.) > > I wonder whether we should consider making the smp memory barriers > inline functions, so these __smp_xxx() variants can be undef'd > afterwards, thereby preventing drivers getting their hands on these > new macros? That'd be tricky to do cleanly since asm-generic depends on ifndef to add generic variants where needed. But it would be possible to add a checkpatch test for this. > -- > RMK's Patch...
2016 Jan 04
0
[PATCH v2 17/32] arm: define __smp_xxx
...th __* > > > unfortunately doesn't stop anyone from using it (been there with > > > other arch stuff before.) > > > > > > I wonder whether we should consider making the smp memory barriers > > > inline functions, so these __smp_xxx() variants can be undef'd > > > afterwards, thereby preventing drivers getting their hands on these > > > new macros? > > > > That'd be tricky to do cleanly since asm-generic depends on > > ifndef to add generic variants where needed. > > > > But it would be possib...
2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the
2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the