Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 4 Apr 2001 04:19:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 4 Apr 2001 04:19:29 -0400 Received: from se1.cogenit.fr ([195.68.53.173]:266 "EHLO se1.cogenit.fr") by vger.kernel.org with ESMTP id ; Wed, 4 Apr 2001 04:19:16 -0400 Date: Wed, 4 Apr 2001 10:18:11 +0200 From: Francois Romieu To: Krzysztof Halasa Cc: linux-kernel@vger.kernel.org Subject: Re: RFC: configuring net interfaces Message-ID: <20010404101811.A6803@se1.cogenit.fr> In-Reply-To: <20010403102734.A27344@se1.cogenit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from khc@intrepid.pm.waw.pl on Tue, Apr 03, 2001 at 03:07:01PM +0200 X-Organisation: Marie's fan club - I Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Krzysztof Halasa ?crit : [...] > But it's still more complicated than the first one and I'm not sure > if doing that is worth it > > > struc sub_req { > > int sub_ioctl; > > ... as we lose 4 bytes here (currently the union of structs in ifreq > is limited to 16 bytes) I missed that. Point taken. [...] > struct ifreq { > char name[16]; > union { > ... > struct { > int sub_command; > int data_length; > void *data; > } > }ifru; > } > > ... while "data" would be fr_protocol, eth_physical etc. > > It's (of course) more complicated, but there is a gain: > - we can have different size requests (from 0 bytes to, say, 100KB) Fine with me (some day we'll surely end passing those data via a read if we need 300Mo but we're not there :o) ). [Other points] Yes. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/