headers
Dag-Erling Smørgrav | 1 Jun 2010 11:15
Picon
Gravatar

Re: BSDCan Toolchain Summit Summary

Brooks Davis <brooks <at> freebsd.org> writes:
> http://wiki.freebsd.org/201005ToolchainSummitSummary

"No new functionality that requires clang/llvm."

How about "No new functionality with non-trivial incompatibilities with
clang/llvm"?

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 6 comments |
headers
Brooks Davis | 1 Jun 2010 18:23
Picon
Favicon

Re: BSDCan Toolchain Summit Summary

On Tue, Jun 01, 2010 at 11:15:26AM +0200, Dag-Erling Sm??rgrav wrote:
> Brooks Davis <brooks <at> freebsd.org> writes:
> > http://wiki.freebsd.org/201005ToolchainSummitSummary
> 
> "No new functionality that requires clang/llvm."
> 
> How about "No new functionality with non-trivial incompatibilities with
> clang/llvm"?

That too.  I'll add it to the real roadmap page once I create it.

As long as people are willing to avoid the darker areas of gcc
misfeatures that shouldn't be a problem in general, but I agree stating
it as a target is a good idea.

-- Brooks
Permalink | Reply | 4 comments |
headers
Robert Watson | 1 Jun 2010 18:38
Picon
Favicon

Re: BSDCan Toolchain Summit Summary


On Tue, 1 Jun 2010, Brooks Davis wrote:

> On Tue, Jun 01, 2010 at 11:15:26AM +0200, Dag-Erling Sm??rgrav wrote:
>> Brooks Davis <brooks <at> freebsd.org> writes:
>>> http://wiki.freebsd.org/201005ToolchainSummitSummary
>>
>> "No new functionality that requires clang/llvm."
>>
>> How about "No new functionality with non-trivial incompatibilities with 
>> clang/llvm"?
>
> That too.  I'll add it to the real roadmap page once I create it.
>
> As long as people are willing to avoid the darker areas of gcc misfeatures 
> that shouldn't be a problem in general, but I agree stating it as a target 
> is a good idea.

I think the gist of our discussion was really about where we can/should 
introduce new dependencies on features specific to clang/llvm.  For example, 
there are some quite interesting ideas about distributing binaries in the LLVM 
intermediate format and doing on-the-fly tuning for the architecture we find 
ourselves running on.  This is pretty neat stuff, but it does mean that it 
won't be available in the immediate future for architectures not supported by 
LLVM or for shops that have to use external non-LLVM-based toolchain parts 
(such as compilers for specific embedded platforms).

I think the consensus from the meeting was that we should start to explore the 
possible, but that key OS features that don't strictly require new 
compiler/etc functionality should not be caused to unnecessarily depend on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Jun 2010 19:10
Picon

Re: BSDCan Toolchain Summit Summary

On Tue, Jun 01, 2010 at 11:23:32AM -0500, Brooks Davis wrote:
> On Tue, Jun 01, 2010 at 11:15:26AM +0200, Dag-Erling Sm??rgrav wrote:
> > Brooks Davis <brooks <at> freebsd.org> writes:
> > > http://wiki.freebsd.org/201005ToolchainSummitSummary
> > 
> > "No new functionality that requires clang/llvm."
> > 
> > How about "No new functionality with non-trivial incompatibilities with
> > clang/llvm"?
> 
> That too.  I'll add it to the real roadmap page once I create it.
> 
> As long as people are willing to avoid the darker areas of gcc
> misfeatures that shouldn't be a problem in general, but I agree stating
> it as a target is a good idea.
> 

You might add a first step to fix FreeBSD's libelf
incompatibilities with other libelf implementations.

http://gcc.gnu.org/ml/gcc/2010-05/msg00381.html

--

-- 
Steve
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Jeremy | 2 Jun 2010 09:54
Picon

Re: BSDCan Toolchain Summit Summary

On 2010-May-31 17:57:32 -0500, Brooks Davis <brooks <at> freebsd.org> wrote:
>http://wiki.freebsd.org/201005ToolchainSummitSummary
>
>This includes a rough draft of a roadmap.  We need to convert this into
>a roadmap page with each required feature listed along with status and 
>contacts.

Thank you for that.  The approach seems reasonable and importing
clang/llvm is a good first step.

One item that doesn't seem to have been mentioned elsewhere is the the
other *BSD Projects - presumably they would also be interested in a
BSD-licensed toolchain.  Have there been any discussions with
representatives from other Projects to investigate a common/shared
path forward?  I believe that the *BSD's are all similar enough that
they could share a common toolchain with minimal local adaptions.  The
benefit for FreeBSD is that a larger userbase will further encourage
"vendor" support.  As a second-order effect, the more diverse users
that clang/llvm has, the faster bugs will be found (and hopefully
fixed).

--

-- 
Peter Jeremy
Permalink | Reply | 0 comments |
headers
Nathan Whitehorn | 2 Jun 2010 21:02
Picon
Favicon

Re: [RFC] Multiboot2 drafting

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> Andrew Reilly wrote:
>>   
>>     
>>> Hi there,
>>>
>>> I know next to nothing about GRUB, and have not yet read the
>>> multiboot spec, but I wonder if you could comment on how or
>>> whether this is related to either the Open Firmware Device Tree
>>> or the Flattened Device Tree used in various embedded OS ports.
>>> It would be cool if there were some convergence going on...
>>>
>>>   
>>>     
>>>       
>> I've looked into it and found good and bad things.
>> Good:
>> -represents the info needed to OS. It's something definitely good and
>> goes in direction we need
>> Bad:
>> -it basically has all the history ballast of OpenFirmware. OFW is
>> supposed to be system-independent but in fact there is a multitude of
>> implementation with various degrees of compatibility. Same goes for
>> device trees. The same information is present in different places with
>> lots of special cases. Many of fields are actually useless variant selectors
>> -it uses string identifiers instead of magic numbers. This makes it more
>> difficult to parse
>> -the most useful information is coming at the leaves and interpretation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Stewart | 2 Jun 2010 23:05

Re: crc32 table

Poul/Matthew:

We actually have the crc32c code in the kernel. It was of
course in the sctp code at one time, but with the use of
it in the NAT and FW code and the advent of the IGB card with
its crc32c offload functions it has been added to:

libkern/crc32.c

Its called  calculate_crc32c(...)

It uses Intel's slicing 8 algorithm as well so its about
as fast as can be...

For SCTP of course the initial c-sum must be set and the
result (after going through all the mbufs) must be complemented....

But it is there.

The file crc32.c does have a traditional crc32 table.. but it seems
unused except by a commented out function crc32(..)... not sure
if somewhere else (maybe in a driver) that table is used (crc32_tab).

R

On May 25, 2010, at 12:37 PM, Poul-Henning Kamp wrote:

> In message <06D5F9F6F655AD4C92E28B662F7F853E021D4D9D <at> seaxch09.desktop.isilon.co
> m>, "Matthew Fleming" writes:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Motin | 7 Jun 2010 00:02
Picon
Favicon

RFC: New event timers infrastructure

Hi.

Most of x86 systems now has at least 4 types of event timers: i8254,
RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
hardcoded and absolutely not scalable. I have reimplemented it, trying
to solve these issues.

I did such things:
 - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c).
It supports global and per-CPU timers, periodic and one-shot. Provides
driver and consumer interfaces for choosing timers and operating them;
 - cleaned existing x86 event timer driver's code and modified it for
new API (x86/isa/atrtc.c, x86/isa/clock.c, x86/x86/local_apic.c). LAPIC
timer is now per-CPU and supports both periodic and one-shot modes;
 - extended HPET driver to support it's event timers in periodic and
one-shot mode (dev/acpica/acpi_hpet.c). Support for per-CPU operation
and FSB interrupts planned for later;
 - written mostly machine-independent mid-layer for managing any present
timers to provide clocks needed for kernel (x86/x86/timeevents.c). It
supports both global and per-CPU timers. Now it supports only periodic
mode, but one-shot mode support planned for later.

All this stuff deeply configurable via both loader tunables on boot and
sysctls in real time:

%sysctl kern.eventtimer
kern.eventtimer.choice: LAPIC(500) HPET(400) HPET1(390) HPET2(390)
i8254(100) RTC(0)
kern.eventtimer.et.LAPIC.flags: 7
kern.eventtimer.et.LAPIC.frequency: 99752386
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ed Schouten | 7 Jun 2010 10:13
Picon
Gravatar

Re: RFC: New event timers infrastructure

Hi Alexander,

* Alexander Motin <mav <at> FreeBSD.org> wrote:
> Most of x86 systems now has at least 4 types of event timers: i8254,
> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
> hardcoded and absolutely not scalable. I have reimplemented it, trying
> to solve these issues.

Just out of curiosity, how does this work relate to things like having a
tickless kernel?

--

-- 
 Ed Schouten <ed <at> 80386.nl>
 WWW: http://80386.nl/
Permalink | Reply | 2 comments |
headers
Ed Schouten | 7 Jun 2010 12:34
Picon
Gravatar

Re: RFC: New event timers infrastructure

Hi Alexander,

* Alexander Motin <mav <at> FreeBSD.org> wrote:
> Ed Schouten wrote:
> > Just out of curiosity, how does this work relate to things like having a
> > tickless kernel?
> 
> It is almost mandatory prerequisite. We can't do any fancy timer stuff
> without unified timer API. Tsuyoshi Ozawa in his Dynamic Ticks work also
> got to the same conclusion, but he was much less aggressive in rewriting
> legacy code.

That's just what I wanted to hear. Thanks!

--

-- 
 Ed Schouten <ed <at> 80386.nl>
 WWW: http://80386.nl/
Permalink | Reply | 0 comments |

Gmane