On Tue, Feb 12, 2019 at 11:41:35PM +0800, cgxu519 wrote:
On 2/12/19 11:20 PM, Greg KH wrote:
On Tue, Feb 12, 2019 at 11:18:22PM +0800, cgxu519 wrote:
On 2/12/19 5:02 PM, Greg KH wrote:
On Tue, Feb 12, 2019 at 04:47:39PM +0800, Chengguang Xu wrote:
Currently chardev allows to share major, showing major with minor range for chardev will be more helpful.
Signed-off-by: Chengguang Xu cgxu519@gmx.com
fs/char_dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c index b25b1da097d5..6f00acdeb308 100644 --- a/fs/char_dev.c +++ b/fs/char_dev.c @@ -55,7 +55,9 @@ void chrdev_show(struct seq_file *f, off_t offset) mutex_lock(&chrdevs_lock); for (cd = chrdevs[major_to_index(offset)]; cd; cd = cd->next) { if (cd->major == offset)
seq_printf(f, "%3d %s\n", cd->major, cd->name);
seq_printf(f, "%3d %s (%u-%u)\n", cd->major, cd->name,
cd->baseminor,
cd->baseminor + cd->minorct - 1);
You are changing the format of a userspace file, what tools are going to break when you do this?
I'll remove this part in V2. Do you have any idea how to get the minor range info for particular major? Or adding a similar file to somewhere under /sys is acceptable?
Why do you need to know the minor range? What can userspace do with this that actually matters?
Assume that when we try to load a driver module and fail with -EBUSY because of minor range overlapping, then what can we do for this case? we even don't know what range has occupied and what range is available.
Why would drivers ever have minor range overlapping? Either they are using a reserved range which is properly documented in the kernel file, or they are using a dynamic range and that will never overlap as they are allocated as needed.
So when has this ever happened in the real world?
Also, I think we can obviously notice range overlapping bugs by showing all registered minor ranges.
Again, how can a range overlap? If so, that's a bug that we can fix now and has nothing to do with the proc file, which will not show an overlap as that can not happen at runtime.
thanks,
greg k-h