Re: [LAD] FOSS Ethernet Soundcard

On Tue, Nov 24, 2009 at 08:35:10PM +0100, Karl Hammar wrote:

> > > uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;
> nothing less. If you haven't listend closely enougth, this was to show
> that you can do the same thing in IPv4 as in IPv6.

That's why I said "unless talking kernel level". The real difference
with IPv6 is that you have plenty of addresses, so you don't have to
abuse an RFC1918 network for a link local address. You just have one
assigned from the kernel, that's all I've said.

And when the kernel assigns and handles it, the app doesn't have to do
it. Which reduces complexity. Which doesn't require an app to be able to
set interface addresses (read: root permissions). Which is, to me, a
good thing. YMMV.

I'm happy to go away and not bother you with the progress network
programming made during the last 10 years.

Speaking of which: IPv4 already has this kind of link-local MAC-derived
addressing: the DHCP fallback block 169.254/16, as specified in RFC3330.

I know that this partially contradicts my argumentation, at least wrt to
auto-assigned link-local addresses.

> Somewhere you have to do the bitstuffing. And if you already
> understand things like this, how would you implement the link local
> address in IPv6?

I don't have to, the kernel already does it. That's all I've said. The
added abstraction and address range makes it so easy for the application
programmer. He doesn't have to care.

And since programming for IPv6 gives you IPv4 for free (dual-use
sockets), coding for IPv4-only clearly isn't beneficial. Of course, you
are free to code whatever you want, but I don't see why one would focus
on IPv4-only when he could get IPv6+IPv4 with modern code. (think of
getaddrinfo() and getnameinfo(). Two functions, no need to know more).

> > struct sockaddr_storage
> So that means that if you didn't work at the networking chair,
> I would be free to ignore you?

You are always free to ignore me. I just see so many code out there in
the wild which has things like

   int ip_addr;

   inet_addr();

and the lot. Perfectly legal in the mid-90ties, but completely
unportable wrt to IPv6. New code shouldn't do this anymore, hence the
rude reflex. My apologies.

-- 
mail: adi@email-addr-hidden  	http://adi.thur.de	PGP/GPG: key via keyserver
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev