Re: [PATCH][2.6.7-mm5] perfctr low-level documentation

From: Mikael Pettersson
Date: Sat Jul 03 2004 - 09:57:49 EST


On Sat, 3 Jul 2004 03:34:13 -0700, Andrew Morton wrote:
>Mikael Pettersson <mikpe@xxxxxxxxx> wrote:
>>
>> On Fri, 2 Jul 2004 15:44:14 -0700, Andrew Morton wrote:
>> >Mikael Pettersson <mikpe@xxxxxxxxx> wrote:
>> >>
>> >> I'm
>> >> considering Christoph Hellwig's suggestion of moving
>> >> the API back to /proc/<pid>/, but with multiple files
>> >> and open/read/write/mmap instead of ioctl. I believe I
>> >> can make that work, but it would take a couple of days
>> >> to implement properly. Please indicate if you would like
>> >> this change or not.
>> >
>> >What would be the advantages of such a change?
>>
>> Eliminating the 6 or so new syscalls I was forced
>> to add when nuking the old ioctl() API.
>
>syscalls are cheap.
>
>> There would be a /proc/<pid>/<tid>/perfctr/ directory
>> with files representing the control data, counter
>> state, general info, and auxiliary control ops.
>
>Futzing around with /proc handlers and mmapping /proc files doesn't sound
>very attractive. Unless we have some solid reason for changing things
>I'd be inclined to leave it as-is. Do you agree?

My only reason was to avoid complaints about adding
syscalls when other interfaces could be made to work.
There are no technical reasons for preferring files
under /proc, in fact it would burden user-space with
having to maintain more state (full path + several
open file descriptors instead of a single fd).

As long as you and Linus don't mind the new syscalls,
I'm happy staying with the current API. I'll start
working on the high-level API documentation then.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/