Hi Bruce,
2011/11/27 Bruce Evans :
> % Index: sys/cam/scsi/scsi_low.h
> % ===
> % --- sys/cam/scsi/scsi_low.h (revision 227956)
> % +++ sys/cam/scsi/scsi_low.h (working copy)
> % @@ -53,10 +53,10 @@
> % #define SCSI_LOW_INTE
On Sat, 26 Nov 2011, Robert Millan wrote:
On Fri, Nov 25, 2011 at 11:16:15AM -0700, Warner Losh wrote:
Hey Bruce,
These sound like good suggestions, but I'd hoped to actually go through all
these files with a fine-toothed comb to see which ones were still relevant.
You've found a bunch of g
This looks fine to me.
Warner
On Nov 26, 2011, at 1:07 PM, Robert Millan wrote:
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@fre
On Fri, Nov 25, 2011 at 11:16:15AM -0700, Warner Losh wrote:
> Hey Bruce,
>
> These sound like good suggestions, but I'd hoped to actually go through all
> these files with a fine-toothed comb to see which ones were still relevant.
> You've found a bunch of good areas to clean up, but I'd like
Hey Bruce,
These sound like good suggestions, but I'd hoped to actually go through all
these files with a fine-toothed comb to see which ones were still relevant.
You've found a bunch of good areas to clean up, but I'd like to humbly suggest
they be done in a follow-on commit.
Warner
On Nov
On Thu, 24 Nov 2011, Robert Millan wrote:
2011/11/24 Bruce Evans :
Now it adds lots of namespace pollution (all of , including
all of its namespace pollution), just to get 1 new symbol defined.
Well, my initial patch (see mail with same subject modulo "v2") didn't
have this problem. Now that
Hi Bruce,
2011/11/24 Bruce Evans :
> Now it adds lots of namespace pollution (all of , including
> all of its namespace pollution), just to get 1 new symbol defined.
Well, my initial patch (see mail with same subject modulo "v2") didn't
have this problem. Now that __FreeBSD_kernel__ is defined,
On Wed, 23 Nov 2011, Robert Millan wrote:
Here we go again :-)
Out of the kernel headers that are installed in /usr/include/ hierracy, there
are some which include support multiple operating systems (usually FreeBSD and
other *BSD flavours).
This patch adds support to detect GNU/kFreeBSD as we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/22/2011 1:21 PM, John Baldwin wrote:
> On Tuesday, November 22, 2011 12:59:19 pm Robert Millan wrote:
>> 2011/11/22 John Baldwin :
>>> Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined
>>> on kFreeBSD?
>>
>> Not currently (except for
2011/11/22 John Baldwin :
>> Not currently (except for kernel-space code), but if all the checks
>> that use __FreeBSD_version are like the one you describe, I think it'd
>> make sense.
>
> I can think of cases where you might want it exposed (e.g. in the parts
> of net-snmp that grovel around in k
On Tuesday, November 22, 2011 12:59:19 pm Robert Millan wrote:
> 2011/11/22 John Baldwin :
> > Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD?
>
> Not currently (except for kernel-space code), but if all the checks
> that use __FreeBSD_version are like the one you descri
Hi Ed,
2011/11/22 Ed Schouten :
>> +#undef __FreeBSD_kernel__
>> +#define __FreeBSD_kernel__
>
> So why not remove the #undef and not let the compiler define it at all?
Well I have no objection if the #undef is removed.
I don't understand why you consider it a problem though. It's not
terribly
Hi Robert,
* Robert Millan , 2022 18:53:
> +#undef __FreeBSD_kernel__
> +#define __FreeBSD_kernel__
So why not remove the #undef and not let the compiler define it at all?
--
Ed Schouten
WWW: http://80386.nl/
pgpNzLA7HWcFI.pgp
Description: PGP signature
2011/11/22 John Baldwin :
> Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD?
Not currently (except for kernel-space code), but if all the checks
that use __FreeBSD_version are like the one you describe, I think it'd
make sense.
But we need to make sure that defining it w
On Tue, Nov 22, 2011 at 11:35:15AM +0200, Kostik Belousov wrote:
> I am fine with __FreeBSD_kernel being empty, please submit the patch.
Here.
--
Robert Millan
Index: sys/sys/param.h
===
--- sys/sys/param.h (revision 227580)
+++ sys
On Monday, November 21, 2011 12:39:26 pm Robert Millan wrote:
> (replying with Debian hat this time)
>
> 2011/11/21 Kostik Belousov :
> > There are some implementations that
> > use FreeBSD kernel, and which could potentially benefit from providing
> > its own value for __FreeBSD_kernel.
>
> Actu
On Mon, Nov 21, 2011 at 06:39:26PM +0100, Robert Millan wrote:
> (replying with Debian hat this time)
>
> 2011/11/21 Kostik Belousov :
> > There are some implementations that
> > use FreeBSD kernel, and which could potentially benefit from providing
> > its own value for __FreeBSD_kernel.
>
> Act
(replying with Debian hat this time)
2011/11/21 Kostik Belousov :
> There are some implementations that
> use FreeBSD kernel, and which could potentially benefit from providing
> its own value for __FreeBSD_kernel.
Actually, we wouldn't be able to provide a different value for the
macro (whatever
On Mon, Nov 21, 2011 at 01:45:29PM +1100, Bruce Evans wrote:
> On Sun, 20 Nov 2011, Kostik Belousov wrote:
>
> >On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote:
> >>On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote:
> >>>I fully agree with an idea that compiler is not a
On Sun, 20 Nov 2011, Kostik Belousov wrote:
On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote:
On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote:
I fully agree with an idea that compiler is not an authorative source
of the knowledge of the FreeBSD version. Even more,
On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote:
> On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote:
> > I fully agree with an idea that compiler is not an authorative source
> > of the knowledge of the FreeBSD version. Even more, I argue that we shall
> > not rely on c
On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote:
> I fully agree with an idea that compiler is not an authorative source
> of the knowledge of the FreeBSD version. Even more, I argue that we shall
> not rely on compiler for this at all. Ideally, we should be able to
> build FreeBSD
On Sat, Nov 19, 2011 at 10:32:50AM +0100, Robert Millan wrote:
> 2011/11/18 Robert Millan :
> > 2011/11/17 John Baldwin :
> >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
> >> so that when compilers are updated to DTRT we will honor their settings?
> >
> > Well, the
2011/11/18 Robert Millan :
> 2011/11/17 John Baldwin :
>> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
>> so that when compilers are updated to DTRT we will honor their settings?
>
> Well, the compiler is supposed to know better than sys/param.h,
I gave this a bit mo
2011/11/17 John Baldwin :
> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
> so that when compilers are updated to DTRT we will honor their settings?
Well, the compiler is supposed to know better than sys/param.h,
because it inherited this number from the runtime kerne
On Thursday, November 17, 2011 2:02:02 pm Robert Millan wrote:
> 2011/11/17 John Baldwin :
> > I recall the discussion from earlier. I can't recall if I had replied to it
> > though. :-/ In my current opinion, I think it would be fine to define
> > __FreeBSD_kernel__ on FreeBSD and to do it in f
2011/11/17 John Baldwin :
> I recall the discussion from earlier. I can't recall if I had replied to it
> though. :-/ In my current opinion, I think it would be fine to define
> __FreeBSD_kernel__ on FreeBSD and to do it in for now until all
> the compilers we use have been updated to define it
On Thursday, November 17, 2011 1:46:33 am Robert Millan wrote:
> 2011/11/16 Warner Losh :
> > My second reaction was why not have
> >
> > #ifndef __FreeBSD_kernel__
> > #define __FreeBSD_kernel__ __FreeBSD__
> > #endif
> >
> > in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in
2011/11/16 Warner Losh :
> My second reaction was why not have
>
> #ifndef __FreeBSD_kernel__
> #define __FreeBSD_kernel__ __FreeBSD__
> #endif
>
> in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in the
> headers that are affected? But I'm not quite sure what effects that wo
.. my suggestion (high level, fluffy) is to try to get
approval/consensus on fixing the immediate problem so things are
consistently horrible, then a second pass to make them consistently
unhorrible.
Adrian
___
freebsd-current@freebsd.org mailing list
h
On Nov 16, 2011, at 11:26 AM, Robert Millan wrote:
> 2011/11/16 Xin LI :
>> Just my $0.02 -- I think we should probably do it in a more
>> centralized place -- otherwise in case someone imported some new code,
>> they have to do the same defined(__FreeBSD__) ||
>> defined(__FreeBSD_kernel__)?
>
Hey Robert,
Thanks for jumping into this. Sadly, it is a bit of a mess. Many of the
"multiple BSD flavor" support #ifdefs are actually quite stale by now, so they
should be cleaned up. That's not something you have to cope with, unless you
want, but it colors my first reaction :)
My second
2011/11/16 Xin LI :
> Just my $0.02 -- I think we should probably do it in a more
> centralized place -- otherwise in case someone imported some new code,
> they have to do the same defined(__FreeBSD__) ||
> defined(__FreeBSD_kernel__)?
How about something like:
#if defined(__FreeBSD__) && !defin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/16/11 09:27, Robert Millan wrote:
> Hi!
>
> Out of the kernel headers that are installed in /usr/include/
> hierracy, there are some which include support multiple operating
> systems (usually FreeBSD and other *BSD flavours).
>
> This patch
34 matches
Mail list logo
