Very Computer

by **Richard Gooc** » Tue, 08 Jan 2002 04:40:15

Quote:Matt Dainty writes:
> Please find attached a patch to add support for devfs to the i386 cpuid and
> msr drivers. Not only that, but it fixes a problem with loading these
> drivers as modules in that the exit hooks on the module never run, (simply
> changing the function prototypes to include 'static' seems to fix this).

> Patch is against 2.4.17. SMP environment isn't tested, but I can't see any
> reason why it wouldn't work...

Looks mostly reasonable, except for:

Quote:> -void __exit cpuid_exit(void)
> +static void __exit cpuid_exit(void)
> {
> - unregister_chrdev(CPUID_MAJOR, "cpu/cpuid");
> + int i;
> + devfs_handle_t parent;
> +
> + for(i = 0; i < NR_CPUS; i++) {
> + parent = devfs_get_parent(devfs_handle[i]);
> + devfs_unregister(devfs_handle[i]);
> + if(devfs_get_first_child(parent) == NULL)
> + devfs_unregister(parent);
> + }
> + devfs_unregister_chrdev(CPUID_MAJOR, "cpu/%d/cpuid");
> }

There is no need to remove the parent /dev/cpu/%d directory, and in
fact it's better not to. All you need is this simpler loop:
for(i = 0; i < NR_CPUS; i++)
devfs_unregister(devfs_handle[i]);

You do something similar in the MSR driver.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **H. Peter Anvi** » Tue, 08 Jan 2002 06:10:10

Once again, this shit does not belong in N drivers; it is core code.

-hpa

> Matt Dainty writes:

>>Please find attached a patch to add support for devfs to the i386 cpuid and
>>msr drivers. Not only that, but it fixes a problem with loading these
>>drivers as modules in that the exit hooks on the module never run, (simply
>>changing the function prototypes to include 'static' seems to fix this).

>>Patch is against 2.4.17. SMP environment isn't tested, but I can't see any
>>reason why it wouldn't work...

> Looks mostly reasonable, except for:

>>-void __exit cpuid_exit(void)
>>+static void __exit cpuid_exit(void)
>> {
>>- unregister_chrdev(CPUID_MAJOR, "cpu/cpuid");
>>+ int i;
>>+ devfs_handle_t parent;
>>+
>>+ for(i = 0; i < NR_CPUS; i++) {
>>+ parent = devfs_get_parent(devfs_handle[i]);
>>+ devfs_unregister(devfs_handle[i]);
>>+ if(devfs_get_first_child(parent) == NULL)
>>+ devfs_unregister(parent);
>>+ }
>>+ devfs_unregister_chrdev(CPUID_MAJOR, "cpu/%d/cpuid");
>> }

> There is no need to remove the parent /dev/cpu/%d directory, and in
> fact it's better not to. All you need is this simpler loop:
> for(i = 0; i < NR_CPUS; i++)
> devfs_unregister(devfs_handle[i]);

> You do something similar in the MSR driver.

> Regards,

> Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **H. Peter Anvi** » Tue, 08 Jan 2002 06:20:14

> H. Peter Anvin writes:

>>Once again, this shit does not belong in N drivers; it is core code.

> Drivers have to register their own device nodes. What kind of API do
> you propose?

The existence of a CPU creates /dev/cpu/# and registering a node
replicates across the /dev/cpu directories.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Richard Gooc** » Tue, 08 Jan 2002 06:20:16

H. Peter Anvin writes:

> > Okey dokey,

> > Please find attached a second, better patch to add devfs support to the i386
> > cpuid and msr drivers. Now it doesn't nuke the cpu/X directories on
> > unloading and only enumerates CPUs based on smp_num_cpus instead of NR_CPUS.

> If you don't understand why this is idiotic, then let me enlighten you:
> there is no sensible reason why /dev/cpu/%d should only be populated
> after having run a CPU-dependent device driver. /dev/cpu/%d should be
> always populated; heck, that's the only way you can sensibly handle
> hotswapping CPUs.

I've already privately told Matt that it would be nice if creation of
/dev/cpu/%d was handled by generic boot code, and not a driver.
However, I don't see that as essential for the CPUID and MSR drivers.

Quote:> I WILL NOT accept a patch as long as devfs is as *ed in the head
> as it currently is. Unfortunately, that seems like it will be a
> long long time.

No need to get rude.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://www.veryComputer.com/
Please read the FAQ at http://www.veryComputer.com/

by **H. Peter Anvi** » Tue, 08 Jan 2002 06:20:17

>>If you don't understand why this is idiotic, then let me enlighten you:
>>there is no sensible reason why /dev/cpu/%d should only be populated
>>after having run a CPU-dependent device driver. /dev/cpu/%d should be
>>always populated; heck, that's the only way you can sensibly handle
>>hotswapping CPUs.

> I've already privately told Matt that it would be nice if creation of
> /dev/cpu/%d was handled by generic boot code, and not a driver.
> However, I don't see that as essential for the CPUID and MSR drivers.

I don't see putting a lot of devfs shit into the CPUID and MSR drivers
as essential in any shape, way or form. Do it right or don't do it at all.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Russell Kin** » Tue, 08 Jan 2002 06:40:06

> The existence of a CPU creates /dev/cpu/# and registering a node
> replicates across the /dev/cpu directories.

And, thus, we decend into more /proc crappyness.

After *lots* of discussion and months of waiting, it was decided between
Alan, David Jones, Jeff Garzik, and other affected parties that
/proc/sys/cpu/#/whatever would be a reasonable. It has even appeared on
lkml a couple of times in the past.

Currently, there is an allocated sysctl number in include/linux/sysctl.h
for /proc/sys/cpu, and it is used by the cpufreq code to provide:

/proc/sys/cpu/#/speed
/proc/sys/cpu/#/speed-max
/proc/sys/cpu/#/speed-min

However, it's true that some of that needs to be pulled out so anything
can use /proc/sys/cpu/#. Just takes the necessary parties to get together
to do the hard work, and with the right hardware to test it out.

--

http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Rusty Russel** » Wed, 09 Jan 2002 20:20:10

On Tue, 8 Jan 2002 11:13:02 +0000

> > So I'd like to propose a new file (say kernel/smp.c) which has generic
> > startup code for each CPU. To start with, it can have a
> > generic_cpu_init() function, which is called by each arch. Note that
> > this function would be called for the boot CPU too.

> Would this also be hacked into whatever Hotswap CPU support exists? Such

We use /proc/sys/cpu/#/. I don't understand what /dev/cpu/xxx is supposed to
do.

It's unfortunate that /proc/sys and /proc suck so hard that good coders go
to great lengths to do anything else [see previous /proc/sys patches].

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **H. Peter Anvi** » Thu, 10 Jan 2002 02:20:16

In newsgroup: linux.dev.kernel

Quote:
> It's unfortunate that /proc/sys and /proc suck so hard that good coders go
> to great lengths to do anything else [see previous /proc/sys patches].

/proc/sys is pretty cool. However, procfs has no permission control
system set up, unlike /dev. This is inherent; adjusting sysctls is a
root-only function and cannot be made otherwise.

-hpa
--

"Unix gives you enough rope to shoot yourself in the foot."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Very Computer

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)

DevFS support for /dev/cpu/X/(cpuid|msr)