search for: unqualifi

Displaying 20 results from an estimated 262 matches for "unqualifi".

Did you mean: unqualify
2010 Mar 26
3
[Bug 1745] New: Matching @cert-authority entries when using unqualified hostnames
https://bugzilla.mindrot.org/show_bug.cgi?id=1745 Summary: Matching @cert-authority entries when using unqualified hostnames Product: Portable OpenSSH Version: -current Platform: Other OS/Version: Other Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy:...
2013 Jul 10
2
[LLVMdev] [BUG] Support unqualified btr, bts
Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.
2013 Jul 10
0
[LLVMdev] [BUG] Support unqualified btr, bts
On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote: > Also, please elaborate on why this is a good change. Because gas accepts it > isn’t sufficient reason in and of itself. That they're valid instructions isn't sufficient reason? Should I additionally say that linux.git uses them? I wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> Also, please elaborate on why this is a good change. Because gas accepts it >> isn’t sufficient reason in and of itself. > > That they're valid instructions isn't sufficient reason? Should I > additionally say that linux.git uses them? > Is the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: > The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. > > The best reference I know of for the AT&T syntax is: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf I'm not sure
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote: > Jim Grosbach wrote: > > No. The above rule is absolutely the wrong thing to do, as has been > > previously noted. > > I don't give a shit about whether you think it is "absolutely wrong" > or not; I did what hpa and the Intel manual outlined. If you have > some _reason_ not to do
2013 Jul 17
1
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de> wrote: > > On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote: > > Jim Grosbach wrote: > > > No. The above rule is absolutely the wrong thing to do, as has been > > > previously noted. > > > > I don't give a shit about whether you think it is
2010 Nov 14
0
PXELINUX: DNS issue on unqualified names
Per doc/pxelinux.txt, the special PXELINUX filename specification of "IP address::filename" allows "IP address" to be a DNS recognizable name. If it contains no dots, the domain name (DHCP option 15) is supposed to be appended to qualify the name. Testing PXELINUX 3.86, this behavior does occur as I can see the DNS request having the specified domain name appended properly.
2010 Nov 14
1
PXELINUX: DNS issue on unqualified names [PATCH][git-pull]
On Sun, Nov 14, 2010 at 10:32, Gene Cumm <gene.cumm at gmail.com> wrote: > Per doc/pxelinux.txt, the special PXELINUX filename specification of > "IP address::filename" allows "IP address" to be a DNS recognizable > name. ?If it contains no dots, the domain name (DHCP option 15) is > supposed to be appended to qualify the name. > > Testing PXELINUX 3.86,
2005 May 25
2
How to force XP to use an unqualified username?
Hi, I'm trying to map a share to a samba server from an XP workstation. The Samba server is a domain member, and the share in question is set up for guest access. >From a linux box, I can run "smbclient -W DOMAIN \\server\share", and it prompts for a password. I hit enter, and it logs in as "anonymous". Looking at a packet trace I see it try to log in as
2010 Mar 18
1
Question about host certificates
...ded the HostCertificate option to the sshd_config and restarted sshd. I've replaced the system's ssh_known_hosts file with one that has a single entry of the form: @cert-authority *.example.domain ssh-rsa ... This works provided that I use the host's FQDn when I ssh to it. If I use an unqualified name, the connection is made but the certificate verification fails. I suppose an entry like @cert-authority *,*.example.domain ssh-rsa ... would work, but it doesn't seem prudent. How are you supposed to specify that the cert-authority is for the local domain? It seem like the name of the...
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself. -Jim On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> The instructions btr and bts are perfectly valid, and have existed since
2013 Jul 11
1
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/ > asm/bitops.h#L68 > > Here is one example that I found. Are the inline assembly arguments > ambiguous in size? It would help us for sure to build the kernel and others. -- JS
2005 May 06
1
oh323 compile problem in FreeBSD
Hi, I'm trying to compile asterisk-oh323-0.7.1 in FreeBSD 5.3. I tried to use gmake but it exits with too many errors. Did somebody compile before oh323 in FreeBSD? How should I compile it under FreeBSD? thanks, Ganbold
2005 May 13
0
[Asterisk-Dev] Re: oh323 compile problem in FreeBSD
...ude/openh323 -I../asterisk-driver -c wrapper_misc.cxx -o wrapper_misc.o In file included from /usr/home/tsgan/pwlib/include/ptlib.h:169, from wrapper_misc.hxx:35, from wrapper_misc.cxx:34: /usr/home/tsgan/pwlib/include/ptlib/unix/ptlib/pdirect.h:78: error: expected unqualified-id before "protected" /usr/home/tsgan/pwlib/include/ptlib/unix/ptlib/pdirect.h:78: error: expected `,' or `;' before "protected" /usr/home/tsgan/pwlib/include/ptlib/unix/ptlib/pdirect.h:80: error: expected constructor, destructor, or type conversion before '*'...
2013 Jul 14
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed
2013 Jul 17
3
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
Jim Grosbach wrote: > No. The above rule is absolutely the wrong thing to do, as has been > previously noted. I don't give a shit about whether you think it is "absolutely wrong" or not; I did what hpa and the Intel manual outlined. If you have some _reason_ not to do that, bring it up. I reported four bugs a few days ago, and the community has shown ZERO (if not NEGATIVE)
2020 May 20
7
CanonicalHostname and ssh connections through a jumphost
raf wrote: > Warlich, Christof wrote: > > ... > > I want to be able to ssh to all internal hosts that live in the internal.sub.domain.net, > > i.e. that are only accessible through the internal.sub.domain.net jumphost without > > having to list each of these hosts somewhere, as they may frequently be added or > > removed from the internal domain and without being