Re: [PATCH] __FreeBSD_kernel__
2011/7/5 Ed Maste : > On the topic of where such a macro should be defined I originally had > no strong opinion. However, valid points have been raised about > compiling software for FreeBSD using compilers that are not the one in > the base system (from ports or otherwise, and GCC or otherwise). This > I think is a very valid point and one that would make me lean towards > defining the macro in sys/param.h. How workable is it to #include > sys/param.h to pick up the macro where needed? That works most of the time. There could be a problem if software can't assume is present, but I think it covers the vast majority of cases. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange 'vmstat -z' output
On Wed, Jul 06, 2011 at 04:40:54AM +0400, Sergey Kandaurov wrote: > On 6 July 2011 02:46, Alexander Best wrote: > > hi there, > > > > i'm seeing the following with 'vmstat -z' on CURRENT, running on amd64: > > > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > 128 Bucket: 1048, 0, 150, 0, 1650,12746, 0 > > > > ...how can the number of failures be greater than the number of requests? > > Here REQ is the total number of successful allocations, not just requests. > I think he is refering to "FAIL" column not REQ. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange 'vmstat -z' output
On Tue, Jul 05, 2011 at 10:46:09PM +, Alexander Best wrote: > hi there, > > i'm seeing the following with 'vmstat -z' on CURRENT, running on amd64: > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > 128 Bucket:1048, 0, 150, 0,1650,12746, 0 > > ...how can the number of failures be greater than the number of requests? > Not to get off track here. Was that sleep patch applied to -CURRENT ? i.e. imported for general usage ? or did you just apply it locally ? If you applied that locally does the same thing happen without it ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: strange 'vmstat -z' output
On 6 July 2011 02:46, Alexander Best wrote: > hi there, > > i'm seeing the following with 'vmstat -z' on CURRENT, running on amd64: > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > 128 Bucket: 1048, 0, 150, 0, 1650,12746, 0 > > ...how can the number of failures be greater than the number of requests? Here REQ is the total number of successful allocations, not just requests. -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
strange 'vmstat -z' output
hi there, i'm seeing the following with 'vmstat -z' on CURRENT, running on amd64: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 128 Bucket:1048, 0, 150, 0,1650,12746, 0 ...how can the number of failures be greater than the number of requests? cheers. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: regression error with calendar
Hi Jaako, > From: Jaakko Heinonen Jaakko Heinonen wrote: > On 2011-07-05, Julian H. Stacey wrote: > > There's a regression error with calendar between FreeBSD-8.1 & 8.2-RELEASES > > Test data: > > - > > Tue+1 TESTX 1 > > Tuesday+1 TESTX 2 > > * Tuesday+1 TESTX 3 > > Tuesday+1 * TESTX 4 > > Tuesday TESTX5 > > Tuesday TESTX6 > > - > > This look like PR bin/155873 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=155873). Ah Yes, that's the same problem. Thanks ! Can FreeBSD please revert the broken code out of CVS, until/ if author / importer / whoever might want to fix it. The new code breaks basic common functionality, to add rare usage exotica. Broken calendar code failed to mail prompt me to call meetings in time. Probably caused lots of missed reminders. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote: > I agree with all of the above reasons, but none of them change the fact > that __linux__ is used left and right to identify both kernel and > userland environments just as __FreeBSD__ is. You choose to disable > __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life > porting software easier and are asking FreeBSD project to cope with > the decision. This breaks compiles of new software with older > compilers than do not define the macro, takes __FreeBSD__ out of > symmetry with __linux__ and other similarly defined platform macros > and forces a race to update every other compiler out there to follow > the suit. I fail to see the benefits out-weighting the drawbacks in > this scenario. There are two separate issues here - the macro itself, and where it's defined. On the topic of the macro itself, __FreeBSD__ implies something about the kernel and the libc, and it used to be the same case for __linux__. This became broken for __linux__ once people started combining a Linux kernel with other than glibc, and it would break if those combining the FreeBSD kernel with another libc defined __FreeBSD__. (A note on terminology - some may dislike the "GNU/" name for various reasons, but either way their project is properly called "Debian GNU/kFreeBSD." I'll refer to it as "kFreeBSD" here for brevity though, since the kFreeBSD part is the unique aspect of this project vs other Debian ports, and the full name is rather awkward to type.) kFreeBSD can't define __FreeBSD__, since it will break any existing software that uses that to infer something about the libc in use. So, that project had a choice; they could have created a new macro __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use. However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes more sense, and actually reduces the porting effort for both them and the FreeBSD porters. Any effort on porting software to the FreeBSD kernel done by either project is then applicable to the other. If kFreeBSD project members make a change to get some piece of software working on a FreeBSD kernel and then gets that change commited upstream we can take advantage of that work without any additional effort on our part. On the topic of where such a macro should be defined I originally had no strong opinion. However, valid points have been raised about compiling software for FreeBSD using compilers that are not the one in the base system (from ports or otherwise, and GCC or otherwise). This I think is a very valid point and one that would make me lean towards defining the macro in sys/param.h. How workable is it to #include sys/param.h to pick up the macro where needed? -Ed Maste ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On Tue, 5 Jul 2011 21:04:41 +0200 Robert Millan wrote: > 2011/7/5 Alexander Kabaev : > > I agree with all of the above reasons, but none of them change the > > fact that __linux__ is used left and right to identify both kernel > > and userland environments > > Yes, __linux__ is used to identify userland. And almost 100% of the > times it is the wrong macro. We've spent several years fixing this > kind of bug. To give just one example among hundreds, here's the > latest incarnation of __linux__ misuse, reported 3 days ago: > > http://lists.debian.org/debian-bsd/2011/07/msg00013.html > > > just as __FreeBSD__ is. > > Not exactly. For example, when you see __FreeBSD__, you know what > libc you're dealing with. > Only because there was no GNU/kFreeBSD before and people got lazy. Using __FreeBSD__ to identify userland can be considered just as wrong practice as using __linux__ for the same purpose, yet several years have been spent fixing this on Linux and quick hack is somehow appropriate for FreeBSD. Why do you keep arguing that intended use of __FreeBSD__ is any different than one of __linux__? It is not and both should be fixed when misused. > > You choose to disable > > __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life > > porting software easier > > If Debian GNU/kFreeBSD enabled __FreeBSD__, software would expect that > it is being built on FreeBSD, and make lots of wrong assumptions. > > Debian GNU/kFreeBSD is not FreeBSD. It is a derivative that builds on > the kernel of FreeBSD and some of its kernel-specific libraries. It's > not surprising that asserting we're FreeBSD via the compiler results > in breakage (to begin with, even GCC headers wouldn't work properly). > Then be a proper OS and have __kFreeBSD__ or what not defined in your toolchain. > (similar statements can be made for e.g. Darwin, which I think you're > familiar with) > Darwin _is_ a proper first-class OS, per above. Last time I checked we were not forced to change out toolchain in any way to cater to their uses of components they borrow from FreeBSD. > > and are asking FreeBSD project to cope with > > the decision. > > I'm asking FreeBSD project to make life easier for a derivative that > is, one way or another, part of its ecosystem, at no cost other than > the time spent discussing the proposal. > Not true, the change does break backward compatibility with older software if the new macro were to be used as you propose, to enable the code that is specific to FreeBSD kernel. > > This breaks compiles of new software with older > > compilers than do not define the macro, > > As far as I'm concerned, new software isn't supposed to rely on this > macro unconditionally untill it is deemed reasonable to do so. > > > takes __FreeBSD__ out of > > symmetry with __linux__ > > I could argue that __FreeBSD_kernel__ would be in symmetry with > __linux__. But that's wordplay. I think we agreed to leave it out of > the list :-) > See above. Why inventing your own symbol as opposed fixing the use of existing one is more appropriate on FreeBSD and not on Linux? > > and other similarly defined platform macros > > and forces a race to update every other compiler out there to follow > > the suit. > > There's no race, and nobody forcing it. > Predefined symbols are only useful if all compilers are consistent in their use. -- Alexander Kabaev signature.asc Description: PGP signature
Re: regression error with calendar
On 2011-07-05, Julian H. Stacey wrote: > There's a regression error with calendar between FreeBSD-8.1 & 8.2-RELEASES > Test data: > - > Tue+1 TESTX 1 > Tuesday+1 TESTX 2 > * Tuesday+1 TESTX 3 > Tuesday+1 * TESTX 4 > Tuesday TESTX5 > Tuesday TESTX6 > - This look like PR bin/155873 (http://www.freebsd.org/cgi/query-pr.cgi?pr=155873). -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/5 Alexander Kabaev : > I agree with all of the above reasons, but none of them change the fact > that __linux__ is used left and right to identify both kernel and > userland environments Yes, __linux__ is used to identify userland. And almost 100% of the times it is the wrong macro. We've spent several years fixing this kind of bug. To give just one example among hundreds, here's the latest incarnation of __linux__ misuse, reported 3 days ago: http://lists.debian.org/debian-bsd/2011/07/msg00013.html > just as __FreeBSD__ is. Not exactly. For example, when you see __FreeBSD__, you know what libc you're dealing with. > You choose to disable > __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life > porting software easier If Debian GNU/kFreeBSD enabled __FreeBSD__, software would expect that it is being built on FreeBSD, and make lots of wrong assumptions. Debian GNU/kFreeBSD is not FreeBSD. It is a derivative that builds on the kernel of FreeBSD and some of its kernel-specific libraries. It's not surprising that asserting we're FreeBSD via the compiler results in breakage (to begin with, even GCC headers wouldn't work properly). (similar statements can be made for e.g. Darwin, which I think you're familiar with) > and are asking FreeBSD project to cope with > the decision. I'm asking FreeBSD project to make life easier for a derivative that is, one way or another, part of its ecosystem, at no cost other than the time spent discussing the proposal. > This breaks compiles of new software with older > compilers than do not define the macro, As far as I'm concerned, new software isn't supposed to rely on this macro unconditionally untill it is deemed reasonable to do so. > takes __FreeBSD__ out of > symmetry with __linux__ I could argue that __FreeBSD_kernel__ would be in symmetry with __linux__. But that's wordplay. I think we agreed to leave it out of the list :-) > and other similarly defined platform macros > and forces a race to update every other compiler out there to follow > the suit. There's no race, and nobody forcing it. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
regression error with calendar
There's a regression error with calendar between FreeBSD-8.1 & 8.2-RELEASES Test data: - Tue+1 TESTX 1 Tuesday+1 TESTX 2 * Tuesday+1 TESTX 3 Tuesday+1 * TESTX 4 Tuesday TESTX5 Tuesday TESTX6 - Data shown with od -c in case any mail or web archive scrambles tabs 000T u e + 1 \t T E S T X X X X X 0201 \n T u e s d a y + 1 \t T E S T 040X X X X X 2 \n * T u e s d a 060y + 1 \t T E S T X X X X X 3 \n 100T u e s d a y + 1 * \t T E S T 120X X X X X 4 \n T u e s d a y \t 140T E S T X X X X X 5 \n T u e s d 160a y \t \t T E S T X X X X X 6 \n \n 200 - Can someone confirm it please ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On Sun, 3 Jul 2011 17:37:30 +0200 Robert Millan wrote: > 2011/7/3 Alexander Kabaev : > > __linux__ is exactly what __FreeBSD__ is and dies not identify > > kernel but rather Linux as whole OS, whatever that might be these > > days. > > > > There does not appear to be an universal macro that identifies > > environment as using Linux kernel regardless of the rest of > > components used (say, to identify Android and Ubuntu or something > > embedded with ucLibc as running Linux kernel with different userland > > implementations). > > I think I'll cowardly try to stick to a practical POV and avoid the > discussion about names that tends to get people excited about :-) > > So from a purely practical perspective: > > - If __linux__ is defined, this implies you're using a specific > kernel. > - If you're using that specific kernel, this implies __linux__ is > defined. > > which explains why using __linux__ to identify the kernel is useful > and reliable. > > Can __linux__ be used to identify more things? Most notably, can > __linux__ be used to identify userland API? > > - If __linux__ is defined, this does not imply you're using GNU libc. > - If you're using GNU libc, this does not imply __linux__ is defined. > > which explains why using __linux__ to identify libc is a bad idea. > However, it can be useful to identify a set of different C libraries > (Glibc, Bionic, uclibc, etc) if they share the property you're > interested in. > > -- > Robert Millan I agree with all of the above reasons, but none of them change the fact that __linux__ is used left and right to identify both kernel and userland environments just as __FreeBSD__ is. You choose to disable __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life porting software easier and are asking FreeBSD project to cope with the decision. This breaks compiles of new software with older compilers than do not define the macro, takes __FreeBSD__ out of symmetry with __linux__ and other similarly defined platform macros and forces a race to update every other compiler out there to follow the suit. I fail to see the benefits out-weighting the drawbacks in this scenario. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [PATCH] __FreeBSD_kernel__
On Sun, 3 Jul 2011 17:47:02 +0200 Robert Millan wrote: > 2011/7/3 Robert Millan : > > 2011/7/3 Alexander Kabaev : > >> Not really, unless you have way of sticking this definition into > >> past compiler releases. > > > > There is one way, but it's slow. It basically involves waiting for > > long enough that any past release of any compiler you care about > > includes the macros you need, before starting to use them. :-) > > However, in the case of FreeBSD, where the compilers are imported into > your codebase, isn't it enough if support is present in the FreeBSD > version of these compilers (for production and development releases of > FreeBSD), plus the latest release of the upstream version of each of > those compilers? > > -- > Robert Millan The slow way would be the right way if you were inclined to really take it. Once old releases of tools that can be broken by the new macro use are long and forgotten we can start on relying on said macro, but not before. I disagree with the notion that we supporting only the imported compiler version is sufficient in FreeBSD. This was a long time deficiency of our development policy and it did more harm than good in the long term. We do want FSF source releases to work work out of the box, and when they do not, it is our loss. I know for a fact that several of our bigger customers are using compilers built for them by a third party and do not rely on the toolchain we supply in source tree. Breaking them would be bad. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [PATCH] FreeBSD compiler extensions
2011/7/5 Roman Divacky : > Why do you need this? Format-extensions are kernel only (which you dont use I > presume) Actually, we compile the kernel of FreeBSD regularly, both 8-STABLE and 9-CURRENT. It is the base of the Debian GNU/kFreeBSD distribution. We've recently ported the build system so that it can be compiled on Debian GNU/Linux as well. You can see build logs here: https://buildd.debian.org/status/package.php?suite=sid&p=kfreebsd-8 https://buildd.debian.org/status/package.php?p=kfreebsd-9&suite=experimental > and no-align-long-strings is boot only (which you dont use either). We don't currently provide the FreeBSD bootloader, though we might do in the future (it just takes someone to be interested enough to make a Debian package). I guess it doesn't hurt to wrap no-align-long-strings as well? (but if you prefer, I can send a patch for format-extensions only). Thanks! -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_cc_version in
On Tue, Jul 5, 2011 at 6:36 AM, Robert Millan wrote: > 2011/7/5 Dimitry Andric : >> As far as I can see, this code only gives warnings when compiled with >> gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to >> just remove the -Wundef flag here? > > Here's a patch to remove -Wundef. I think it's a bad idea however, > IMHO it's better to fix the cause of the warning instead. The problem is that, IIRC, C guarantees that an undefined symbol when checked in a #if context will evaluate to 0. So -Wundef checks for warnings on compliant code. Personally I have no objection to the original patch. Cheers, matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_cc_version in
2011/7/5 Dimitry Andric : > As far as I can see, this code only gives warnings when compiled with > gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to > just remove the -Wundef flag here? Here's a patch to remove -Wundef. I think it's a bad idea however, IMHO it's better to fix the cause of the warning instead. -- Robert Millan Index: sys/conf/kern.mk === --- sys/conf/kern.mk(revision 223736) +++ sys/conf/kern.mk(working copy) @@ -5,7 +5,7 @@ # CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ - -Wundef -Wno-pointer-sign -fformat-extensions \ + -Wno-pointer-sign -fformat-extensions \ -Wmissing-include-dirs -fdiagnostics-show-option # # The following flags are next up for working on: ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Unit Tests for FreeBSD Kernel APIs?
On 06/24/2011 03:14 PM, John Baldwin wrote: > On Friday, June 24, 2011 3:23:11 am Sebastian Huber wrote: >> Hello, >> >> exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9), >> condvar(9), etc.? >> >> Have a nice day! > > Hmm, I have a kernel module that does some tests, but it is not in the tree. > One of the issues is that many of the tests you want to do for some of these > APIs involve timing. For rwlocks, for example, I used KTR traces and used > a kernel module that forked 4 threads to all compete over a single lock. I > then verified via KTR traces that every branch was taken (and made liberal > use of KASSERT()s which caught a few edge cases I had missed initially). > The background for my question is that we want to use the FreeBSD 8.2 network and USB stack for another operating system (RTEMS). Thus we have to implement several core APIs in terms of our operating system services. -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_cc_version in
Am 05.07.2011 12:11, schrieb Dimitry Andric: > On 2011-07-04 18:30, Robert Millan wrote: >> This patch fixes a (harmless) warning when is parsed by >> upstream version of GCC. >> >> -#if __FreeBSD_cc_version >= 31 && defined(__GNUC__) && >> !defined(__INTEL_COMPILER) >> +#if defined(__FreeBSD_cc_version) && __FreeBSD_cc_version >= 31 >> && defined(__GNUC__) && !defined(__INTEL_COMPILER) > > As far as I can see, this code only gives warnings when compiled with > gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to > just remove the -Wundef flag here? > > Additionally, it looks like the C standard is a bit vague about whether > the preprocessor uses short-circuited boolean evaluation (although gcc's > manual says it does), so I'm not sure whether this patch solves the > problem properly either. The CPP #if argument is a /constant-expression/, according to K&R's The C Programming language 2nd ed., so it shall short-circuit. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_cc_version in
On 2011-07-04 18:30, Robert Millan wrote: This patch fixes a (harmless) warning when is parsed by upstream version of GCC. -#if __FreeBSD_cc_version >= 31 && defined(__GNUC__) && !defined(__INTEL_COMPILER) +#if defined(__FreeBSD_cc_version) && __FreeBSD_cc_version >= 31 && defined(__GNUC__) && !defined(__INTEL_COMPILER) As far as I can see, this code only gives warnings when compiled with gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to just remove the -Wundef flag here? Additionally, it looks like the C standard is a bit vague about whether the preprocessor uses short-circuited boolean evaluation (although gcc's manual says it does), so I'm not sure whether this patch solves the problem properly either. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] FreeBSD compiler extensions
On 07/ 5/11 03:27 PM, Robert Millan wrote: This patch conditionalizes a pair of FreeBSD compiler extensions so that its CFLAGS are only used on FreeBSD. Were I work we don't spend much time on compiling any kernel, but I'm superficially curious about the actual code which necessitates you needing these different flags. Is this for performance, correctness or both? (If you have any sort of reduced code example you can share that would be great) From a biased vendor perspective - less lock-in to a single compiler is usually a good thing. (The linux kernel may be the best example of what not to do.) Sorry I can't comment on the correctness of the patch. ./C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] FreeBSD compiler extensions
Why do you need this? Format-extensions are kernel only (which you dont use I
presume) and no-align-long-strings is boot only (which you dont use either).
Hm? :)
roman
On Tue, Jul 05, 2011 at 10:27:51AM +0200, Robert Millan wrote:
> This patch conditionalizes a pair of FreeBSD compiler extensions so
> that its CFLAGS are only used on FreeBSD.
>
> --
> Robert Millan
> Index: sys/conf/kern.mk
> ===
> --- sys/conf/kern.mk (revision 223736)
> +++ sys/conf/kern.mk (working copy)
> @@ -1,11 +1,21 @@
> # $FreeBSD$
>
> +.if !defined(OPSYS)
> +OPSYS!= uname -s
> +.endif
> +
> #
> # Warning flags for compiling the kernel and components of the kernel:
> #
> +.if ${OPSYS} == "FreeBSD"
> +# FreeBSD extension, not available in upstream GCC
> +format_extensions= -fformat-extensions
> +no_align_long_strings= -mno-align-long-strings
> +.endif
> +
> CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
> - -Wundef -Wno-pointer-sign -fformat-extensions \
> + -Wundef -Wno-pointer-sign ${format_extensions} \
> -Wmissing-include-dirs -fdiagnostics-show-option
> #
> # The following flags are next up for working on:
> @@ -32,7 +42,7 @@
> #
> .if ${MACHINE_CPUARCH} == "i386"
> .if ${CC:T:Mclang} != "clang"
> -CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
> +CFLAGS+= ${no_align_long_strings} -mpreferred-stack-boundary=2 -mno-sse
> .else
> CFLAGS+= -mno-aes -mno-avx
> .endif
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: priv_check() question
On Sun, 3 Jul 2011, exorcistkiller wrote: Hi! I am taking a FreeBSD course this summer and I'm doing a homework. A new system call uidkill() is to be added. uidkill(uid_t uid, int signum) sends signal specified by signum to all processes owned by uid, excluding the calling process itself. I'm almost done, however I get stuck with priv_check(). If the calling process is trying to send signal to processes owned by others, permission should be denied. My implementation simply uses an if (p->p_ucred->cr_uid == ksi.ksi_uid) to deny it, however priv_check() is required. My question is: what privilege a process should have to send signal to processes owned by others? PRIV_SIGNAL_DIFFCRED? The right way to think about "privileges" in FreeBSD is that they exempt subjects (usually processes) from normal access control rules -- typically as a result of a root uid. The access control rules for signalling are captured by p_cansignal() and cr_cansignal(), depending on whether the "subject" is a process or a cached credential. Processes have access to slightly greater rights than raw credentials due to additional context -- for example, information about parent-child relationships. These functions then invoke further privilege checks if required, perhaps overriding the normal requirement that uids match, etc. kill() implements a couple of broadcast modes for signals -- you may want to look at the implementation there to see how this is done. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[PATCH] FreeBSD compiler extensions
This patch conditionalizes a pair of FreeBSD compiler extensions so
that its CFLAGS are only used on FreeBSD.
--
Robert Millan
Index: sys/conf/kern.mk
===
--- sys/conf/kern.mk(revision 223736)
+++ sys/conf/kern.mk(working copy)
@@ -1,11 +1,21 @@
# $FreeBSD$
+.if !defined(OPSYS)
+OPSYS!=uname -s
+.endif
+
#
# Warning flags for compiling the kernel and components of the kernel:
#
+.if ${OPSYS} == "FreeBSD"
+# FreeBSD extension, not available in upstream GCC
+format_extensions= -fformat-extensions
+no_align_long_strings= -mno-align-long-strings
+.endif
+
CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
- -Wundef -Wno-pointer-sign -fformat-extensions \
+ -Wundef -Wno-pointer-sign ${format_extensions} \
-Wmissing-include-dirs -fdiagnostics-show-option
#
# The following flags are next up for working on:
@@ -32,7 +42,7 @@
#
.if ${MACHINE_CPUARCH} == "i386"
.if ${CC:T:Mclang} != "clang"
-CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse
+CFLAGS+= ${no_align_long_strings} -mpreferred-stack-boundary=2 -mno-sse
.else
CFLAGS+= -mno-aes -mno-avx
.endif
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
