> I am not aware of any real technical issues, except that
> it needs to be done for both 32bit and 64bit.
Some good documentation on when you need vmalloc_sync_all(), and
why most places don't need it would help to avoid a surge of
patches spraying calls to it all over the kernel.
-Tony
---
>> Happen to have more details? If they really run in user context their
>> priv level would be the same right, otherwise they run in something
>> weird, not quite user not quite kernel. Now that might be the case, but
>> I'm utterly ignorant on itanic.
>
> See Documentation/ia64/fsys.txt
Summary
> - or the PMU capability is expressed as a special counter type (if it's
> useful enough) - and then either the write() method or ioctl is extended
> to express attributes we want to set/change while a counter is running.
The product of:
{exotic PMU modes} * {creative performance meas
>> $ git checkout -b corey origin/perfmon3
>>
> Tony, do I have to do this on the repository, so we can name it directly?
I don't think so ... I think this is just the way git works
now. Back at the beginning of git time when you cloned a
repository the "master" branch of the remote repository
b
> % git checkout origin/perfmon3
> Note: moving to "origin/perfmon3" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b
> HEAD is now at f738655... perfmon: refr
> On that page is a commit number:
>
> commit f57e91682d141ea50d8c6d42cdc251b6256a3755
That is a commit in linus tree but it isn't the -rc9 one.
$ git-rev-parse --verify v2.6.26-rc9^0
b7279469d66b55119784b8b9529c99c1955fe747
But you may not need to leap through these hoops. If you have
b
> Except that the data passed for one or the other may not be the same.
> However, it is true that as of today the PMC information is a subset of
> the PMD's.
True the PMDs are generally scalar values while the PMCs are often
bitmasks of feature bits ... but so long as they both fit into the
same
> To go further, we could also group the write syscalls : pfm_write_regs(int
> fd, int type, void *arg, size_t arg_sz) with type
> indicating either config or data registers.
>
> What do you think?
What about encoding control/data in the register number? E.g. negative
numbers for config, and posi
