Re: CVS commit: src/sys/dev/pci
In message: 100702193931.m0105...@mirage.ceres.dti.ne.jp Izumi Tsutsui tsut...@ceres.dti.ne.jp writes: : Module Name:src : Committed By: msaitoh : Date: Fri Jul 2 03:25:27 UTC 2010 : : Modified Files: : src/sys/dev/pci: pucdata.c : : Log Message: : Fix frequency for OX16PCI954. : : I'm afraid some puc's frequencies are not chip specific : but board specific, i.e. the same chips could have different clocks : and we might also have to check svend and sprod in such case. Even that won't be enough. We've hit this problem in FreeBSD. There's two boards that are totally the same from a software perspective, but the frequencies are different. Warner
Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib
In message: 20100626032531.ga14...@britannica.bec.de
Joerg Sonnenberger jo...@britannica.bec.de writes:
: On Sat, Jun 26, 2010 at 05:11:39AM +0200, Alistair Crooks wrote:
: On Sat, Jun 26, 2010 at 01:32:05AM +0200, Joerg Sonnenberger wrote:
: On Fri, Jun 25, 2010 at 11:54:32PM +0200, Alistair Crooks wrote:
:Even in C99, the %lu method will work unless size_t is bigger
than
:unsigned long *and* the value being printed exceeds ULONG_MAX,
which
:is unlikely to happen in practice.
:
: Please get the attributions right - I was quoting that text.
:
: Actually, it doesn't. This method breaks as soon as size_t != u_long and
: might only work in a few edge cases like the size_t being the last
: argument and the byte order is Little Endian. This is worse because IIRC
: Microsoft decided to use IL32LLP64 or something similarly fancy.
:
: Can you give us a reference to this, please?
:
: E.g.
:
http://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
: and the MSDN reference inside.
:
: A more portable approach with autoconf can be found in pkg_install, look
: for MISSING_SIZE_T_SUPPORT and the corresponding AC_CHECK_SIZEOF calls
: in configure.ac.
:
: Hmmm, I see this in configure.ac -
:
: AC_CHECK_SIZEOF(int)
: AC_CHECK_SIZEOF(long)
: AC_CHECK_SIZEOF(long long)
: AC_CHECK_SIZEOF(size_t, [#include stdlib.h])
:
: ...compute the sizes to not depend on SIZE_MAX (which would simplify the
: logic a lot).
:
: and
:
: case $host in
: *-*-hpux*)
: AC_DEFINE(MISSING_SIZE_T_SUPPORT)
: AH_TEMPLATE([MISSING_SIZE_T_SUPPORT], [
: Define to 1 if the `z' modifider for printf is missing.
: ])
: ;;
: esac
:
: The only platform for pkgsrc purposes ATM which lacks the %z support.
:
: and
:
: #ifndef MISSING_SIZE_T_SUPPORT
: # define PRIzu zu
: #elif SIZEOF_SIZE_T == SIZEOF_INT
: # define PRIzu u
: #elif SIZEOF_SIZE_T == SIZEOF_LONG
: # define PRIzu lu
: #elif SIZEOF_SIZE_T == SIZEOF_LONG_LONG
: # define PRIzu llu
: #else
: # errror Unknown size_t size
: #endif
:
: Not quite what I'd been expecting, though, from the glowing description
: above.
:
: It would be simpler if SIZE_MAX support can be assumed. In that case it
: would boil down to
: #if SIZE_MAX == INT_MAX
: #define PRIzu u
: #elif SIZE_MAX == LONG_MAX
: #define PRIzu lu
: #else SIZE_MAX == LLONG_MAX
: #define PRIzu llu
: #endif
You could easily enough have something like the following in autoconf
to generate that:
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
size_t foo = ~0;
printf(#ifndef SIZE_MAX\n#define SIZE_MAX %llu\n#endif\n,
(unsigned long long)foo);
return (0);
}
Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: 20100614083424.gc16...@cs.hut.fi Antti Kantee po...@cs.hut.fi writes: : On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote: : On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: :Fix previous in emul.c -- only numbers are operands for cpp comparisons. :Apparently non-numbers logically produce arch-dependent behaviour. : : Not at all. : : C99 6.10.1 #4: : :[...] After all replacements due to macro expansion and the defined :unary operator have been performed, all remaining identifiers :(including those lexically identical to keywords) are replaced with :the pp-number 0, and then each preprocessing token is converted into :a token. The resulting tokens compose the controlling constant :expression which is evaluated according to the rules of 6.6. [...] : : So, you being the person who attempted to write cpp with sed, what : comparison does amd64 == sun3 actually result in? What about : i386 == sun3 (the former returned true, the latter didn't). On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: 20100615052154.gb16...@netbsd.org David Holland dholland-sourcechan...@netbsd.org writes: : On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: : On i386, that's true. amd64 expands to '0', as does sun3. This makes : the first one true. The second one, i386 expands to '1', so the : second one would be false. : : Arguably we shouhld fix our gcc to only define __i386__, not i386, : which conflicts with the user namespace... True, but doing so would likely break applications that have depended on this define. Which is worse? Warner
Re: CVS commit: src/usr.bin/make
In message: huonge$v4...@dough.gmane.org
chris...@astron.com (Christos Zoulas) writes:
: In article 20100609171621.ga23...@britannica.bec.de,
: Joerg Sonnenberger jo...@britannica.bec.de wrote:
: On Wed, Jun 09, 2010 at 12:58:23PM -0400, Christos Zoulas wrote:
: Log Message:
: Explain variable expansion better. Requested by Aleksey Cheusov
:
: This is wrong. Loop variables are not exapnded on each loop iteration.
: Each loop iteration effectively creates a new variable. The rest of his
: confusion comes from two simple facts:
: (1) += is lazy in bmake. This is different from FreeBSD, where it forces
: expansion.
: (2) The evaluation of j is lazy as well. That's why he sees the last
: loop iteration.
:
: Well, it was true when I wrote the for code (more than 16 years
: ago!). I guess dsl re-wrote it, but the net effect is the same.
:
: When did FreeBSD changed += not to be lazy? That would break a lot
: of existing Makefiles I presume.
It looks like it is lazy to me for all non-loop variables in FreeBSD:
% uname
FreeBSD
% cat M
FOO=1
BAR=2
.for j in a b c
FOO+= ${BAR} ${j}
.endfor
BAR=3
all:
@echo ${FOO}
@echo ${BAR}
% make -f M
1 3 a 3 b 3 c
3
%
Not sure if this is correct or expected but it strikes me as
useful and changes to this behavior would break things...
Warner
Re: CVS commit: src/lib/libc/locale
In message: 20100606041254.gb19...@netbsd.org David Holland dholland-sourcechan...@netbsd.org writes: : On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote: :Module Name: src :Committed By:tnozaki :Date:Wed Jun 2 16:04:52 UTC 2010 : :Modified Files: : src/lib/libc/locale: bsdctype.c : :Log Message: :uint8_t - unsigned char, int16_t - short. : : As ever, thank you for looking after our locale code. : : I was just wondering why this change was made? It seems to be a backwards : step to me? : : I looked at it and it appears to me that it's a change to use : non-sized types (that are guaranteed to be large enough) in the : in-memory structures. If we ever do a port to a 36-bit machine or : whatever it's probably desirable. If you ever port to a 36-bit machine, you are going to have to lie and define int32_t as 'int' anyway Warner
Re: CVS commit: src/sys/conf
In message: 201001010039.o010dvjh028...@vtn1.victoria.tc.ca jnem...@victoria.tc.ca (John Nemeth) writes: : On May 23, 6:34pm, John Nemeth wrote: : } : } Module Name:src : } Committed By: jnemeth : } Date: Thu Dec 31 23:59:02 UTC 2009 : : Bah! One minute early, got confused. Mea Culpa. For penance I : shall remove myself from the race for the next two years. Generally, copyright in the last half of the year goes to the next year anyway, so a few seconds is no big deal :) Warner
Re: CVS commit: src/external/bsd/mdocml/dist
In message: 20091107084411.gt15...@snowdrop.l8s.co.uk David Laight da...@l8s.co.uk writes: : On Sat, Nov 07, 2009 at 12:48:16AM -0700, M. Warner Losh wrote: : : which ones have the same name, but different behavior on OS X? A quick read : of the man pages suggests they are identical... : : Check about whether they need a \n at the end of the format. They aren't needed on MacOS, nor FreeBSD. A quick test on 10.5.8 shows that warn doesn't need it. Is there one that does need them? Warner
Re: CVS commit: src/sys/rump
In message: 20090908131801.gb17...@cs.hut.fi Antti Kantee po...@cs.hut.fi writes: : On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote: : In article 20090907174634.ga16...@cs.hut.fi, : Antti Kantee po...@netbsd.org wrote: : On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote: : : Module Name: src : Committed By: pooka : Date: Mon Sep 7 13:02:37 UTC 2009 : : Modified Files: :src/sys/rump: Makefile.rump : : Log Message: : Always define __NetBSD__ (for builds on non-NetBSD) : : : when does this happen? even builds on non-NetBSD should : end up here with a compiler that defines __NetBSD__. : : When you are building the binaries to be used as libraries on non-NetBSD, : i.e. not building NetBSD itself. : : Then perhaps we should be using a different CPP symbol? : : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which : was imported from $OtherOS, you must have the rump version think it is : running on NetBSD, since it technically speaking is. The difference to : most cpp symbols is merely that __NetBSD__ comes from the compiler instead : of from the kernel headers. Of course param.h could define something like : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD : kernel code, but I don't see any benefit, especially since __NetBSD__ : is a well established practise even outside NetBSD developers. __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. You need to use a different symbol. This is a bug in the NetBSD code now. __NetBSD__ isn't, and never has bene, the KERNEL. : Maybe it's easier to understand this issue if you think of rump as a : highly componentized OS running inside a virtual machine. Just instead : of qemu or xen or what have you, your vmm is a process -- nobody is : saying xen code shouldn't use __NetBSD__, are they? I'd say that it shouldn't... : I think Matt understood my extended offline explanation yesterday, : so maybe he could chime in and summarize? Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD kernel build environment specific (since it comes from sys/parma.h) and doesn't muddy the waters with the differences between the different BUILD systems. Warner
Re: CVS commit: src/sys/rump
In message: 20090908162339.ga11...@cs.hut.fi Antti Kantee po...@cs.hut.fi writes: : On Tue Sep 08 2009 at 12:18:57 -0400, Christos Zoulas wrote: : | : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* : | : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which : | : was imported from $OtherOS, you must have the rump version think it is : | : running on NetBSD, since it technically speaking is. The difference to : | : most cpp symbols is merely that __NetBSD__ comes from the compiler instead : | : of from the kernel headers. Of course param.h could define something like : | : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD : | : kernel code, but I don't see any benefit, especially since __NetBSD__ : | : is a well established practise even outside NetBSD developers. : | : | __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. : | You need to use a different symbol. This is a bug in the NetBSD code : | now. __NetBSD__ isn't, and never has bene, the KERNEL. : : That was my complaint exactly. I meant to say this in my next message :-) : : | Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD : | kernel build environment specific (since it comes from sys/parma.h) : | and doesn't muddy the waters with the differences between the : | different BUILD systems. : : That is what I was thinking also. : : Whoever finds this churn worth their effort, as dh pointed out, remember : to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, : __Slowaris__, __sMackOS__, __etc__ as well. How many instances of those are there? And wouldn't it be spelled __linsux__? :) Warmer
Re: CVS commit: src/usr.bin/error
In message: 20090814021047.91ed856...@rebar.astron.com chris...@zoulas.com (Christos Zoulas) writes: : On Aug 13, 10:19pm, dholland-sourcechan...@netbsd.org (David Holland) wrote: : -- Subject: Re: CVS commit: src/usr.bin/error : : | On Thu, Aug 13, 2009 at 03:46:39PM +, Christos Zoulas wrote: : | XXX: does this program actually do anything useful these days? : | : | Yes, it works just fine :-) I use it all the time. : | : | Better you than me :-) : | : | Maybe it should lose support for compilers that disappeared twenty : | years ago, though. : : The error reporting syntax has not changed much! Besides, how much space would it really save? Warner
Re: PCI domains
In message: 20090710024528.ec36959...@thoreau.thistledown.com.au Simon Burge sim...@netbsd.org writes: : Christoph Egger wrote: : : Michael Lorenz wrote: : : +/* : + * NetBSD's userland has a /dev/pci* entry for each bus but userland has no way : + * to tell if a bus is a subordinate of another one or if it's on a different : + * host bridge. : : I have a patch which introduces support for PCI domains. It allows the : userland to distinguish between them by checking if the pci bus belongs : to the same PCI domain. : : What exactly is a PCI domain? A quick google seems to suggest that : this is a Linux concept as opposed to a PCI concept. In a previous : life we used NetBSD on a number of different machines of various : architectures that had multiple PCI host bridges, although admittedly we : didn't need to know the topology of the PCI bus layout. PCI domains, as implemented by Linux and FreeBSD are separate host bridges. Each bus complex behind the host bridge has independent numbering. Each of these bus complexes are in a different domain. Not all systems with multiple host bridges have separate numbering domains, but many do. Warner
Re: CVS commit: src/sbin/fsck_ffs
In message: 87r5yv4rqn@snark.cb.piermont.com Perry E. Metzger pe...@piermont.com writes: : : M. Warner Losh i...@bsdimp.com writes: : What I didn't glean from the discussion is what, exactly, you were : going to do about it and what, exactly, you'd like to harmonize with : FreeBSD on. It may have been there, but I just missed it. : : Documentation. It would involve making all man pages refer consistently : to FFS, FFSv1, FFSv2, and not to mix in the references to UFS. Documentation is easy, and I'll be happy to bring over the changes. Output of programs and/or input via config file changes is harder... I wasn't sure which of these two classes you were asking... Warner
Re: CVS commit: src/sbin/fsck_ffs
In message: 20090510220227.gd16...@britannica.bec.de Joerg Sonnenberger jo...@britannica.bec.de writes: : On Sun, May 10, 2009 at 04:31:34AM +, YAMAMOTO Takashi wrote: : have you tried to convince freebsd guys to use your preferred name? : being different creates another layer of confusion. : : We had a short discussion about this during BSDCan. Kirk didn't mind and : if it should be reasonable to get consistent. I think that this sort of decision can't be made by just Kirk since FreeBSD has deployed ufs2 for several releases now. I've missed much of the discussion, can someone recap exactly what you'd like to see changed? That would be the starting point for any user-visisble changes to FreeBSD... Warner
Re: CVS commit: src/sbin/fsck_ffs
In message: 20090511015855.gd16...@britannica.bec.de Joerg Sonnenberger jo...@britannica.bec.de writes: : On Sun, May 10, 2009 at 07:51:41PM -0600, M. Warner Losh wrote: : I've missed much of the discussion, can someone recap exactly what : you'd like to see changed? That would be the starting point for any : user-visisble changes to FreeBSD... : : There is currently a mixed naming convention when refering to FFS : filesystems (v1 and v2). Sometimes, it is FFS, FFS2, UFS, UFS2 etc. : The consensus in NetBSD was to consistently use FFS and FFSv2. : UFS2 is bad, as it changes the underlaying inode format, but still has : FFS on top. Right, I gleaned that from the discussion. What I didn't glean from the discussion is what, exactly, you were going to do about it and what, exactly, you'd like to harmonize with FreeBSD on. It may have been there, but I just missed it. Warner
