[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2d7436a1001071313r6f5814c9o9d7b2d1c6e162367@mail.gmail.com>
Date: Thu, 7 Jan 2010 22:13:18 +0100
From: Michał Mirosław <mirqus@...il.com>
To: "Maciej W. Rozycki" <macro@...ux-mips.org>
Cc: Joe Perches <joe@...ches.com>,
H Hartley Sweeten <hartleys@...ionengravers.com>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] lib/vsprintf.c: Add %pMF to format FDDI bit reversed MAC
addresses
2010/1/7 Maciej W. Rozycki <macro@...ux-mips.org>:
> On Thu, 7 Jan 2010, Joe Perches wrote:
>> On Mon, 2010-01-04 at 23:43 +0000, Maciej W. Rozycki wrote:
>> > The example below shows an address, and the sequence of bits or symbols
>> > that would be transmitted when the address is used in the Source Address
>> > or Destination Address fields on the MAC header. The transmission line
>> > shows the address bits in the order transmitted, from left to right. For
>> > IEEE 802 LANs these correspond to actual bits on the medium. The FDDI
>> > symbols line shows how the FDDI PHY sends the address bits as encoded
>> > symbols.
>> >
>> > MSB: 35:7B:12:00:00:01
>> > Canonical: AC-DE-48-00-00-80
>> > Transmission: 00110101 01111011 00010010 00000000 00000000 00000001
>> > FDDI Symbols: 35 7B 12 00 00 01"
>> >
>> > Please note that this address has its group bit clear.
>> >
>> > This notation is also defined in the "FDDI MEDIA ACCESS CONTROL-2
>> > (MAC-2)" (X3T9/92-120) document although that book does not have a need
>> > to use the MSB form and it's skipped.
>>
>> Adds 56 bytes to object size
>>
>> New:
>> $ size lib/vsprintf.o
>> text data bss dec hex filename
>> 8714 0 2 8716 220c lib/vsprintf.o
>> old:
>> $ size lib/vsprintf.o
>> text data bss dec hex filename
>> 8658 0 2 8660 21d4 lib/vsprintf.o
>
> What's the gain? I'd be rather conservative when taking everybody's 56
> bytes for one or two drivers hardly anybody uses. The format of MAC
> addresses is unlikely to change, so I'd say the sources can live with
> one or two places where the strings are formatted manually. Even if the
> drivers lose more than these 56 bytes.
Maybe this can be Kconfig-selected by the relevant drivers then?
BTW, the gain is of course consistency and code readability.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists