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
les however, except in cases where I had
to modify that line anyway.
I think it's a good compromise between my initial patch and an exhaustive
cleanup of those headers (which I'm probably not the most indicate for).
--
Robert Millan
Index: sys/cam/scsi/scsi_low.h
==
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,
declarations as FreeBSD does (which is to be expected in kernel
headers, since both systems share the same kernel).
--
Robert Millan
Index: sys/cam/scsi/scsi_low.h
===
--- sys/cam/scsi/scsi_low.h (revision 227831)
+++ sys/cam/scsi
land, like it happens with
>> __FreeBSD__.
>
> Correct. I don't believe that is the case since normally one has to
> check for __FreeBSD__ before using __FreeBSD_version.
Makes sense. I'll bring this up in debian-bsd mailing list.
Thanks for the tip
--
Robert Millan
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
ation so often, so this
possibility AFAIK has never been discussed. I had it in my TODO to
bring it up.
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any m
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 227
t.
Just to make it clear: It's no problem to me if it's defined as a
number, but it doesn't help much either. At least from Debian POV it's
not worth making a big argument about. It could be a good idea from
FreeBSD POV, but please only
> That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ?
> And then make more strong wording about other systems that use the macro,
> e.g. remove 'may' from the kFreeBSD example.
> Also, please remove the smile from comment.
Ok. New patch at
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/p
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
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
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
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
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 adds support to detect GNU/kFreeBSD as well. In all cases, we
match the same declarations as FreeBSD d
2011/9/2 John Baldwin :
> A more useful test would be to alter pmap.h so it says:
>
> #ifndef NKPT
> #define NKPT doesnt_compile
> #endif
Uhm fair enough, thanks for the explanation John.
--
Robert Millan
___
freebsd-current@freebsd.o
.
> Do you know of any C files that do
> are using NKPT (or values derived from it) without including opt_pmap.h?
Many. To obtain a full list, I suggest you put something like:
#ifdef NKPT
#warning nkpt:good
#else
#warning nkpt:bad
#endif
in pmap.h and build with "WERRO
the value specified in config. Or worse, it may even use
different values for different .c files.
--
Robert Millan
Index: kfreebsd-9/sys/amd64/include/pmap.h
===
--- kfreebsd-9.orig/sys/amd64/include/pmap.h 2011-08-31 22:26:06.0
mity a
compelling reason to change their view, without forcing them into it.
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl comparison will identify 900039 as
new ABI.
Petr is that correct?
--
Robert Millan
___
freebsd-current@freebsd.org maili
ility in userland, but if I understand correctly we do this
already and our only supported upgrade path is "first upgrade kernel,
then userland" anyway.
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
2011/6/29 Hans Petter Selasky :
>> What about urio?
>
> Hi,
>
> urio is not used for booting the kernel, so it is not important that it is in
> the kernel.
Ah, ok. I thought /dev/urio0 was a block device.
--
Robert Millan
__
2011/6/24 Hans Petter Selasky :
> I would like to request testing of the attached
> patch before I commit it. The patch is about only having ukbd, ums and umass
> per default in the kernel GENERIC config file(s).
What about urio?
--
Robe
d be modified to scan for PCI cards via libpci on initialization
and generate "fake" events for them?
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscrib
l resolved. What would be the point of keeping
them in memory after devd has finished parsing the config files?
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, se
2011/6/24 Hans Petter Selasky :
> Updated bus_auto.conf:
>
> http://hselasky.homeunix.org:8192/bus_auto.conf
Very nice. But why not use variable names instead of hardcoding numbers? It
makes the output much easier to understand.
--
Robe
27 matches
Mail list logo
