On 08.07.2018 17:44, Kamil Rytarowski wrote:
> I will try to scratch a new header unaligned.h with the set of macros
> and submit it to evaluation.
I've prepared a scratch of unaligned.h with get_unaligned():
http://netbsd.org/~kamil/kubsan/unaligned.h
There are at least two problems to
On 09.07.2018 16:58, Thor Lancelot Simon wrote:
> On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote:
>>
>> The C11 standard could indeed use consistent wording. In one place
>> "correctly aligned" in other alignment "restrictions" and
>> "requirements". None of these terms is marked
In article <20180709145848.ga21...@panix.com>,
Thor Lancelot Simon wrote:
>On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote:
>>
>> The C11 standard could indeed use consistent wording. In one place
>> "correctly aligned" in other alignment "restrictions" and
>> "requirements".
On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote:
>
> The C11 standard could indeed use consistent wording. In one place
> "correctly aligned" in other alignment "restrictions" and
> "requirements". None of these terms is marked as a keyword or term and I
> read them in the
On 09.07.2018 11:32, Martin Husemann wrote:
> On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote:
>> According to my understanding, alignment requirement for a type/object
>> is implementation defined (6.2.8); however during the process of
>> converting types, if the returned pointer
On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote:
> According to my understanding, alignment requirement for a type/object
> is implementation defined (6.2.8); however during the process of
> converting types, if the returned pointer is not correctly aligned the
> result is
On 09.07.2018 10:09, Martin Husemann wrote:
> On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote:
>> Misaligned pointer is explicitly documented as undefined behavior in the
>> C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.)
>
> Yes, but the standard dos not define
On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote:
> Misaligned pointer is explicitly documented as undefined behavior in the
> C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.)
Yes, but the standard dos not define what a misaligned pointer is
(or "correctly aligned").
>>> Misaligned pointer is explicitly documented as undefined behavior
>>> in the C standard (C11 6.3.2.3 p7).
>> So what? Do you have reason to think that sys/arch/x86 will at some
>> point be ported to a compiler [] that does something unexpected with
>> that code?
> Due to UB a compiler is free
On 08.07.2018 17:30, Mouse wrote:
> Caveat: this is all opinion. I'm not the one doing the work here.
>
> src/sys/arch/x86/x86: mpbios.c
>
> Remove unaligned access to mpbios_page[]
>
> sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address
> 0x800031c7a413
On 08.07.2018 17:16, Jason Thorpe wrote:
>
>
>> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote:
>>
>> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least
>> for the use of acpica (which still contains a fallback for Itanium
>> without misaligned access, but not actively
Caveat: this is all opinion. I'm not the one doing the work here.
src/sys/arch/x86/x86: mpbios.c
Remove unaligned access to mpbios_page[]
sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address
0x800031c7a413 for type 'const __uint16_t' which requires 2
> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote:
>
> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least
> for the use of acpica (which still contains a fallback for Itanium
> without misaligned access, but not actively maintained).
>
> Linux uses a different approach
On 08.07.2018 15:53, Jaromír Doleček wrote:
> Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit :
>> I've introduced the change to mpbios.c as it was small, selfcontained
>> and without the need to decorate the whole function.
>
> Am I reading the code wrong or you actually introduced bug
Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit :
> I've introduced the change to mpbios.c as it was small, selfcontained
> and without the need to decorate the whole function.
Am I reading the code wrong or you actually introduced bug in mpbios.c?
Shouldn't this:
memtop |=
On 08.07.2018 11:24, Martin Husemann wrote:
> On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Sat Jul 7 23:05:50 UTC 2018
>>>
>>> Modified Files:
>>> src/sys/arch/x86/x86: mpbios.c
>>>
>>> Log Message:
We could use the reference counter in struct cfdriver to keep driver
modules busy, but I'm not sure if the system can figure out what's
unneeded if a needed driver might be one for a hotpluggable device.
Would you treat those drivers differently? What about drivers (if_ath_pci
comes to mind)
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
duplicating match data in module.plist.
This sounds like a step in the right direction (recording
I think you'd just need to find a way to supply that data for built-in
modules too.
On Tue, 18 Oct 2011, David Young wrote:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the
# David Young 2011-10-18:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
duplicating match data in module.plist.
This sounds like a step
On Tue, Oct 18, 2011 at 12:50:58PM -0400, Jachym Holecek wrote:
# David Young 2011-10-18:
On Tue, Oct 18, 2011 at 11:28:22AM -0400, Jared McNeill wrote:
I played around with driver module autoloading a while back, and it
worked pretty well but the implementation I came up with required
21 matches
Mail list logo
