On Tue, Feb 2, 2016 at 4:28 PM, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2016 at 4:25 PM, H. Peter Anvin wrote:
>> On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>s>>
Should it be possible to resuse free_init_pages() and/or
free_reserved_area() only for routines (members in the arra
On Tue, Feb 2, 2016 at 4:25 PM, H. Peter Anvin wrote:
> On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>>
>>> Should it be possible to resuse free_init_pages() and/or
>>> free_reserved_area() only for routines (members in the array in this
>>> case of a struct of fns) that don't meet our subarc
On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>
>> Should it be possible to resuse free_init_pages() and/or
>> free_reserved_area() only for routines (members in the array in this
>> case of a struct of fns) that don't meet our subarch once we're done
>> iterating over the routies and know we c
On Fri, Jan 22, 2016 at 1:52 PM, Luis R. Rodriguez
wrote:
> On Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin wrote:
>> On 01/22/2016 05:44 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>>
Something that confuses me is that gcc seems to give these section
On Tue, Feb 2, 2016 at 3:48 PM, H. Peter Anvin wrote:
> On 01/22/2016 05:44 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>
>>> Something that confuses me is that gcc seems to give these sections the
>>> "aw" attributes which makes as complain. This might be a g
On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>
>> Something that confuses me is that gcc seems to give these sections the
>> "aw" attributes which makes as complain. This might be a gcc bug.
>
> Workaround: use an (possibly empty) intializer:
On Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin wrote:
> On 01/22/2016 05:44 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>
>>> Something that confuses me is that gcc seems to give these sections the
>>> "aw" attributes which makes as complain. This might be a
On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>
>> Something that confuses me is that gcc seems to give these sections the
>> "aw" attributes which makes as complain. This might be a gcc bug.
>
> Workaround: use an (possibly empty) intializer:
Hi,
On Thu, 21 Jan 2016, H. Peter Anvin wrote:
> Something that confuses me is that gcc seems to give these sections the
> "aw" attributes which makes as complain. This might be a gcc bug.
Workaround: use an (possibly empty) intializer:
struct foo {int i;};
const struct foo
__attribute__((use
On 21/01/16 21:37, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:
Sure, do we know if that ICC compatible? Do we care? There are a
series of ICC hacks put in place on ipxe's original solution which
I've folded in, it seems that works but if we car
On Thu, Jan 21, 2016 at 03:56:35PM -0800, H. Peter Anvin wrote:
> On 01/21/16 14:25, Luis R. Rodriguez wrote:
> > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> > wrote:
> >>> Sure, do we know if that ICC compatible? Do we care? There are a
> >>> series of ICC hacks put in place on ipxe'
On 01/21/16 14:25, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
> wrote:
>>> Sure, do we know if that ICC compatible? Do we care? There are a
>>> series of ICC hacks put in place on ipxe's original solution which
>>> I've folded in, it seems that works but if w
On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk
wrote:
>> Sure, do we know if that ICC compatible? Do we care? There are a
>> series of ICC hacks put in place on ipxe's original solution which
>> I've folded in, it seems that works but if we care about ICC those
>> folks should perhaps help
On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:
> On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin wrote:
> > On 12/17/15 20:40, H. Peter Anvin wrote:
> >>>
> >>> const struct
> >>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
> >>>
> >>> const struc
On Thu, Jan 21, 2016 at 12:19 PM, H. Peter Anvin wrote:
> On 12/17/15 20:40, H. Peter Anvin wrote:
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>>
>>> const struct
>>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>>> tablename
On 12/17/15 20:40, H. Peter Anvin wrote:
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0];
>>
>> const struct
>> foo__attribute__((used,section(".rodata.tbl.tablename.999")))
>> tablename__end[0];
>>
(Over)thinking about this some more, I suggest using
On Wed, Jan 20, 2016 at 1:16 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 15, 2015 at 02:16:29PM -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> A long time ago in a galaxy far,
>> far away...
>
> :-)
>
> You wouldn't have this on a git tree by any c
On Tue, Dec 15, 2015 at 02:16:29PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> A long time ago in a galaxy far,
> far away...
:-)
You wouldn't have this on a git tree by any chance?
And thank you for doing this!
___
On December 18, 2015 10:50:40 AM PST, "Luis R. Rodriguez"
wrote:
>On Thu, Dec 17, 2015 at 08:25:19PM -0800, H. Peter Anvin wrote:
>> On 12/17/15 15:46, Luis R. Rodriguez wrote:
>> >
>> > I explain why I do that there but the gist of it is that on Linux
>we may also
>> > want stronger semantics f
On Thu, Dec 17, 2015 at 08:25:19PM -0800, H. Peter Anvin wrote:
> On 12/17/15 15:46, Luis R. Rodriguez wrote:
> >
> > I explain why I do that there but the gist of it is that on Linux we may
> > also
> > want stronger semantics for specific linker table solutions, and solutions
> > such
> > as t
On 12/17/15 20:25, H. Peter Anvin wrote:
>
> /* DECLARE_LINKTABLE_RO */
> extern const struct foo tablename[], tablename__end[];
>
> /* DEFINE_LINKTABLE_RO */
> DECLARE_LINKTABLE_RO(struct foo, tablename);
>
> const struct
> foo__attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0
On 12/17/15 15:46, Luis R. Rodriguez wrote:
>
> I explain why I do that there but the gist of it is that on Linux we may also
> want stronger semantics for specific linker table solutions, and solutions
> such
> as those devised on the IOMMU init stuff do memmove() for sorting depending on
> sema
On Thu, Dec 17, 2015 at 3:46 PM, Luis R. Rodriguez wrote:
> solutions such
> as those devised on the IOMMU init stuff do memmove() for sorting depending on
> semantics defined (in the simplest case here so far dependency between init
> sequences), this makes each set of sequences very subsystem sp
On Thu, Dec 17, 2015 at 12:38:10PM -0800, H. Peter Anvin wrote:
> I think we can make this even more generic. In particular, I would love
> to see a solution for link tables that:
>
> a) can be used for any kind of data structures, not just function
> pointers (the latter is a specialization of t
I think we can make this even more generic. In particular, I would love
to see a solution for link tables that:
a) can be used for any kind of data structures, not just function
pointers (the latter is a specialization of the former);
b) doesn't need any changes to the linker scripts once the ini
On December 15, 2015 2:16:29 PM PST, "Luis R. Rodriguez"
wrote:
>From: "Luis R. Rodriguez"
>
> A long time ago in a galaxy far,
> far away...
>
>Konrad Rzeszutek Wilk posted patches which eventually got merged to
>help
>with modularizing the IOMMUs we have on x86 [0]. Thi
From: "Luis R. Rodriguez"
A long time ago in a galaxy far,
far away...
Konrad Rzeszutek Wilk posted patches which eventually got merged to help
with modularizing the IOMMUs we have on x86 [0]. This work was done due to
the complex relationship that exists on IOMMUs and
27 matches
Mail list logo
