search for: unqualify

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:

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.

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

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.

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

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

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

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

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

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.

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,

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

Hi, I'm experimenting with host certificates in 5.4p1 and seem to have hit a usability issue. I've generated a host certificate, added 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

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

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

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

Following is the errors when I tried to compile oh323 in FreeBSD 5.3. Asterisk is updated from cvs. asterisk# gmake for x in wrapper asterisk-driver; do gmake -C $x build || exit 1 ; done make: illegal option -- - usage: make [-BPSXeiknqrstv] [-C directory] [-D variable] [-d flags] [-E variable] [-f makefile] [-I directory] [-j max_jobs] [-m directory] [-V variable]

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

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)

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