[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.tg5c8vr2iudtyh@master>
Date: Mon, 09 Oct 2006 12:05:11 +0200
From: "Thomas Maier" <balagi@...tmail.de>
To: "Peter Osterlund" <petero2@...ia.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/11] 2.6.18-mm3 pktcdvd: make procfs interface optional
Hello,
Am 05.10.2006, 21:59 Uhr, schrieb Peter Osterlund <petero2@...ia.com>:
> Given the fact that Linus doesn't allow breaking user space tools
> unless absolutely necessary, I don't think it makes sense to be able
> to disable the character device control code.
Hmm, since it will be optional to leave the procfs interface in the
kernel, it is on the admin / distribution builder to decide this.
I know only one tool that uses this interface (pktsetup), maybe there
are others, but if the sysfs interface will be available in future (?),
there is another (simple) option to control the driver, using simple
shell commands e.g.
And i read anywhere, that procfs should only contain process information
in a far away (?) future ;)
> Therefore a patch that unconditionally moves
> /proc/driver/pktcdvd/pktcdvd? to debugfs would make a lot of sense.
Then move it to debugfs and drop it from procfs.
> Also, the current change has another problem:
>
> static int pkt_seq_show(struct seq_file *m, void *p)
> +{
> + struct pktcdvd_device *pd = m->private;
> + char buf[1024];
> +
> + pkt_print_info(pd, buf, sizeof(buf));
> + seq_printf(m, "%s", buf);
> + return 0;
> +}
>
> This wastes 1K stack space, and it can corrupt the stack if the
> pkt_print_info() function wants to write more than 1K data.
Ok, 1k is a little bit high, since only about 300 chars are written
into the buffer currently.
But also, pkt_print_info() would only write sizeof(buf) chars into
the buffer.
-Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists