[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18235.45103.397753.321892@cargo.ozlabs.ibm.com>
Date: Thu, 15 Nov 2007 13:34:23 +1100
From: Paul Mackerras <paulus@...ba.org>
To: David Miller <davem@...emloft.net>
Cc: hch@...radead.org, akpm@...ux-foundation.org, gregkh@...e.de,
mucci@...utk.edu, eranian@....hp.com, wcohen@...hat.com,
robert.richter@....com, linux-kernel@...r.kernel.org,
andi@...stfloor.org
Subject: Re: [perfmon] Re: [perfmon2] perfmon2 merge news
David Miller writes:
> From: Paul Mackerras <paulus@...ba.org>
> Date: Thu, 15 Nov 2007 12:11:10 +1100
>
> > The third (hard to extend cleanly) is a good point, and is a valid
> > criticism of the current set of perfmon2 system calls, I think.
> > However, the goal of being able to extend the interface tends to be in
> > opposition to the goal of having strong typing of the interface.
> > Things like a multiplexed syscall or an ioctl are much easier to
> > extend but that is at the expense of losing strong typing.
>
> I disagree.
>
> With netlink we can just add new attributes when a new need arises for
> a particular interface. The attribute code describes the type
> precisely, so there is no loss of strong typing at all.
Well you must mean something different by "strong typing" from the
rest of us. Strong typing means that the compiler can check that you
have passed in the correct types of arguments, but the compiler
doesn't have any visibility into what structures are valid in netlink
messages.
In any case, I think that adding a structure size argument to the
current perfmon2 system calls where appropriate would mean that we
could extend them cleanly later on if necessary. It would mean that
we could add fields at the end, and that the kernel could know what
version of the structures that userspace was using.
Paul.
-
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