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