On 2/21/12 9:13 AM, Marcel Moolenaar wrote:
On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote:
On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote:
On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote:
Is the target though _binary_ compatibility? Just having a blessed
method of do
On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote:
> On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote:
>> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote:
>>> Is the target though _binary_ compatibility? Just having a blessed
>>> method of doing accessor method things will buy
On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote:
> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote:
> > Is the target though _binary_ compatibility? Just having a blessed
> > method of doing accessor method things will buy more source
> > flexibility. The KBI can stay the same in th
On Mon, Feb 20, 2012 at 16:37, Adrian Chadd wrote:
> On 20 February 2012 16:15, Luigi Rizzo wrote:
>
>>> The concept seems fine to me and I like that it might simplify future
>>> API changes. Have you verified that if_get_*() accessors don't add
>>> significant overhead?
>>
>> the vast majority
On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote:
> Is the target though _binary_ compatibility? Just having a blessed
> method of doing accessor method things will buy more source
> flexibility. The KBI can stay the same in the default case and IMHO
> this kind of thing gives developers more pow
On 20 February 2012 18:21, Juli Mallett wrote:
>
> It's not just about Juniper, though, it's about us, and how much this
> buys us. Using inlines buys us some source compatibility and the
> ability to add some invariants, but is no different to macros in terms
> of KBI within a version of FreeBSD
On 20 February 2012 16:15, Luigi Rizzo wrote:
>> The concept seems fine to me and I like that it might simplify future
>> API changes. Have you verified that if_get_*() accessors don't add
>> significant overhead?
>
> the vast majority of these fields are only accessed in the control path,
> not
On Mon, Feb 20, 2012 at 05:16:02PM -0600, Brooks Davis wrote:
>
> The concept seems fine to me and I like that it might simplify future
> API changes. Have you verified that if_get_*() accessors don't add
> significant overhead?
the vast majority of these fields are only accessed in the control
On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote:
> All,
>
> Juniper is in the final phases of creating a clean separation
> between FreeBSD and Junos, so as to make upgrades of FreeBSD
> easier. This also allows Juniper to track -current and be more
> active FreeBSD contributors.
2012/2/19 Julian Elischer :
>> For example: you can introduce a define that either old or
>> new drivers use to indicate whether they need full visibility
>> or whether an abstract type works. This then drives what is
>> defined/declared and how it's defined/declared.
>>
> The trouble is that core
On 2/17/12 7:48 AM, Marcel Moolenaar wrote:
On Feb 17, 2012, at 5:53 AM, Gleb Smirnoff wrote:
M> Thoughts, feedback and suggestion are welcome,
Is it possible to make the structure the driver points to opaque?
Once made, that would allow us to hack on the ifnet (or on its
successor - iflogica
On 2/17/12 5:53 AM, Gleb Smirnoff wrote:
On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote:
M> Thoughts, feedback and suggestion are welcome,
Is it possible to make the structure the driver points to opaque?
Once made, that would allow us to hack on the ifnet (or on its
success
On 17 February 2012 09:18, Luigi Rizzo wrote:
> I definitely agree that it is a good investment, especially considering that
> I am doing this all the times when i port FreeBSD stuff to linux...
>
> The linux version of netmap, which i just completed, was mostly
> done playing tricks to remap str
On Fri, Feb 17, 2012 at 08:52:31AM -0800, Marcel Moolenaar wrote:
>
> On Feb 17, 2012, at 12:23 AM, Luigi Rizzo wrote:
> >>
> >> Thoughts, feedback and suggestion are welcome,
> >
> > I do like the idea, but the amount of changes will be massive
> > (see below). The thing that worries me the mos
On Feb 17, 2012, at 12:23 AM, Luigi Rizzo wrote:
>>
>> Thoughts, feedback and suggestion are welcome,
>
> I do like the idea, but the amount of changes will be massive
> (see below). The thing that worries me the most is that it
> will introduce huge changes between different releases, unless
>
On Feb 17, 2012, at 5:53 AM, Gleb Smirnoff wrote:
> M> Thoughts, feedback and suggestion are welcome,
>
> Is it possible to make the structure the driver points to opaque?
>
> Once made, that would allow us to hack on the ifnet (or on its
> successor - iflogical) more aggressively without breaki
On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote:
M> All,
M>
M> Juniper is in the final phases of creating a clean separation
M> between FreeBSD and Junos, so as to make upgrades of FreeBSD
M> easier. This also allows Juniper to track -current and be more
M> active FreeBSD contribu
On 17 February 2012 00:23, Luigi Rizzo wrote:
> I do like the idea, but the amount of changes will be massive
> (see below). The thing that worries me the most is that it
> will introduce huge changes between different releases, unless
> we backport the accessors (while keeping the underlying str
On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote:
> All,
>
> Juniper is in the final phases of creating a clean separation
> between FreeBSD and Junos, so as to make upgrades of FreeBSD
> easier. This also allows Juniper to track -current and be more
> active FreeBSD contributors.
Hi,
I honestly quite like this idea.
Adrian
On 16 February 2012 20:16, Marcel Moolenaar wrote:
> All,
>
> Juniper is in the final phases of creating a clean separation
> between FreeBSD and Junos, so as to make upgrades of FreeBSD
> easier. This also allows Juniper to track -current and be mo
20 matches
Mail list logo
