Re: if_data size issues

From: Julian Elischer (julian_at_elischer.org)
Date: 09/02/04

  • Next message: M. Warner Losh: "Re: if_data size issues" 
    Date: Thu, 02 Sep 2004 00:49:56 -0700
To: Brooks Davis <brooks@one-eyed-alien.net>

    Brooks Davis wrote:
    > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote:
    >
    >>In a later message, Brooks Davis wrote:
    >>
    >>>Given the pain this change is causing and the limited impact of
    >>>reducing the precision of ifi_epoch, I propose the following:
    >>>
    >>>- Back out the ifi_epoch addition.
    >>>- MT5 and MT4 Peter's size change.
    >>>- Turn ifi_unused into ifi_epoch.
    >>
    >>Given the time-constraints in that we want a solution "right now",
    >>these seem like good ideas.
    >
    >
    > I've done the backout and will submit Peter's change for MT5 on the 4th.
    > I'll do the ifi_unused => ifi_epoch change soon, but I need to verify my
    > theory that I can use a time_t without changing the struct size.
    >
    >
    >>>- After 5.3 is released, declare that upgrades to 6.0 from releases
    >>> other then 4.x (x>=11) and 5.y (y>=3) require special handling
    >>> and allow if_data to grow as demand requires.
    >>>- If additional precision is deemed necessary at some future date,
    >>> add a second ifi_epoch_tv.
    >>
    >>We do not have to come to an agreement on these steps until we are
    >>ready to make additional changes to the structure. Something along
    >>these lines seems reasonable to me, but I don't think that we have
    >>to declare any specific timetables right now.
    >
    >
    > Agreed. I think it would be useful to declare upfront that should a
    > change be made, we are willing to jetison full, offical support for
    > upgrades to 6.0 from 5.x (x<3), but that's a minor detail.

    yes I believe 5.2->6.0-current@X
    where X is a point in time a bit down the road, is not an important
    conversion, as very few people will be doing it...
    those who are running 5.2 will probably jump to either 5.3 or 6.0
    within a relatively short time.
    those who go to 6 from 4 will probably go to 4.11 or more or 5.3+ first.

    >
    > -- Brooks
    >

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: if_data size issues"

    Relevant Pages

    • Re: if_data size issues
      ... Brooks Davis wrote: ... >>Given the pain this change is causing and the limited impact of ... theory that I can use a time_t without changing the struct size. ... I think it would be useful to declare upfront that should a ...
      (freebsd-arch)
    • Re: Cast to a struct?
      ... Neither the source expression nor the target type of a cast is ... allowed to be a struct (except that any expression can be cast to ... A cast specifies a type conversion. ... unsigned int is exactly 32 bits. ...
      (comp.lang.c)
    • GURUS: VB .NET alternatives to C# type conversion operators and operator overloading?
      ... I have implemented a struct in C# which acts as a sort of a variant type, ... For the conversion purpose I had to implement static conversion operators, ... or MyStruct = CType ... I wrote the following in VB as a test, just the constructors and the ...
      (microsoft.public.dotnet.framework)
    • Re: pointer to array of const objects
      ... > encapsulate an array inside a struct. ... "typedef" only creates an alias. ... anywhere in the conversion process. ...
      (comp.lang.c)
    • Re: Compiler chooses conv ctor - why?
      ... struct A { ... conversion function should be chosen, as according to 13.3.3.2of the standard, it is better function due to qualification conversion required by conversion constructor? ...
      (microsoft.public.vc.language)