lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ