Christoph Egger writes:
> Izumi Tsutsui wrote:
>>> Now, of course, that doesn't come as a surprise. Some people just never
>>> learn or listen. Or apologise.
>>
>> Honestly, I'd like to see proper fixes for output of
>> "grep -r 'memcpy( ' sys/arch" ,
>> before another set of mechanical change
I wrote:
> > Maybe ahc(4) was the only one that was broken. The point is that you
> > could have found this by comparing the object files.
>
> Although ahc(4) has many quirks (to share sources among *BSD/Linux),
> only aic7xxx_osm.c belongs to ahc(4) and it doesn't have any bad cast,
> per output
> > Honestly, I'd like to see proper fixes for output of
> > "grep -r 'memcpy( ' sys/arch" ,
> > before another set of mechanical changes.
>
> I broke it, so I will fix it.
> Do you want to review the patch ?
Well, it isn't functional changes at all.
Can you check it yourself before calling for r
Izumi Tsutsui wrote:
>> Now, of course, that doesn't come as a surprise. Some people just never
>> learn or listen. Or apologise.
>
> Honestly, I'd like to see proper fixes for output of
> "grep -r 'memcpy( ' sys/arch" ,
> before another set of mechanical changes.
I broke it, so I will fix it.
> Now, of course, that doesn't come as a surprise. Some people just never
> learn or listen. Or apologise.
Honestly, I'd like to see proper fixes for output of
"grep -r 'memcpy( ' sys/arch" ,
before another set of mechanical changes.
---
Izumi Tsutsui
> Maybe ahc(4) was the only one that was broken. The point is that you
> could have found this by comparing the object files.
Although ahc(4) has many quirks (to share sources among *BSD/Linux),
only aic7xxx_osm.c belongs to ahc(4) and it doesn't have any bad cast,
per output of grep adapt_dev sys
On Tue, May 12, 2009 at 05:15:05PM +0100, Robert Swindells wrote:
>
> Christoph Egger wrote:
> >> Valeriy E. Ushakov wrote:
> >> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> >>
> >> >> struct device * -> device_t, no functional changes intended.
> >>
> >> >Why don't you cmp(
Robert Swindells wrote:
> Christoph Egger wrote:
>>> Valeriy E. Ushakov wrote:
On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> struct device * -> device_t, no functional changes intended.
Why don't you cmp(1) the objects before and after to verify that?
"Same obj
Christoph Egger wrote:
>> Valeriy E. Ushakov wrote:
>> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>>
>> >> struct device * -> device_t, no functional changes intended.
>>
>> >Why don't you cmp(1) the objects before and after to verify that?
>> >"Same object code generated" i
> Do a search in sys/dev/ic for 'adapt_dev', any driver that casts this
> to a softc instead of calling device_private() will crash.
struct device * and device_t are identical, so they won't crash
unless softc will actuall be split from device_t.
But I don't see benefits by mechanical changes aga
>
> Valeriy E. Ushakov wrote:
> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>
> >> struct device * -> device_t, no functional changes intended.
>
> >Why don't you cmp(1) the objects before and after to verify that?
> >"Same object code generated" is, unlike intentions, somet
On Tue, May 12, 2009 at 04:24:07PM +0100, Robert Swindells wrote:
>
> Valeriy E. Ushakov wrote:
> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>
> >> struct device * -> device_t, no functional changes intended.
>
> >Why don't you cmp(1) the objects before and after to verify t
Valeriy E. Ushakov wrote:
>On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>> struct device * -> device_t, no functional changes intended.
>Why don't you cmp(1) the objects before and after to verify that?
>"Same object code generated" is, unlike intentions, something that can
>be
On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> struct device * -> device_t, no functional changes intended.
Why don't you cmp(1) the objects before and after to verify that?
"Same object code generated" is, unlike intentions, something that can
be verified.
SY, Uwe
--
u...@std
14 matches
Mail list logo
