Messages in this thread | | | Date | Sat, 10 Jun 2006 13:56:58 +0800 | From | "Antonino A. Daplas" <> | Subject | Re: [PATCH 2/5] VT binding: Add sysfs support |
| |
Greg KH wrote: > On Sat, Jun 10, 2006 at 08:38:18AM +0800, Antonino A. Daplas wrote: >> Greg KH wrote: >>> On Fri, Jun 09, 2006 at 04:39:51PM +0800, Antonino A. Daplas wrote: >>>> Add sysfs attributes for binding and unbinding VT console drivers. The >>>> attributes are located in /sys/class/tty/console and are namely: >>>> >>>> A. backend - list registered drivers in the following format: >>>> >>>> "I C: Description" >>> No, this violates the "one value per file" issue with sysfs. How do you >>> know you will not overflow the buffer passed to you? >> I was wondering about this. I just want a way to show what are the currently >> loaded drivers, so it's a read-only attribute. It's using snprintf (though >> I haven't added a check for possible overflows, should be a 2-liner). Maximum >> number of lines is 16, and there are examples of this rule-breakage in the >> current sysfs tree. >> >> /sys/class/usb_host/usb_hostx/device/pools > > Ah, thanks for pointing this out. Those files should go to debugfs, > they do NOT belong in sysfs at all. > >> Yes, none are valid excuses. Anyway, what would be the best way? I was >> considering creating another class for vt_console, but that would entail >> the creation of a new device major number just for this. > > No, you don't need a major to create a new class in sysfs at all. Look > at usb_host for an example of that :)
Aha, I see it now. Yes, this is exactly what I need. Thanks for the tip.
> Ok, I also read the 0/5 in this series which describes this in detail, > sorry for not seeing that (hint, cc: everyone on the series that one > too, so they get a bit of detail in the future.) >
Sorry about that, slipped my mind.
Tony
- 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/
| |