Re: Wait for console to become available, v3.2
By now, pretty much everone is probably up to speed on what the USB folks are telling us: There is no way to avoid using some sort of timeout to decide whether the console is ever going to appear. So: 1. We want the minimum timeout possible so that headless systems will not be delayed any more than is necessary to detect that no console is available. 2. As I understand it, USB devices don't generally come with any guarantee what the maximum time to initialize will be. Therefore, as far as I can see, this means that we can't empirically determine an appropriate timeout until we know what USB devices are connected to a particular system. This, in turn, means that any default timeout we might choose will have to have a command line parameter to override it. Naturally, we want to help a user determine as easily as possible just how long it took to detect whatever serial device they may want to use so that they can set the timeout so the system will boot as quickly as possible when being used in a headless mode. This probably means picking a stable point from which to start measuring the timeout, as well as printing how long it took to detect the console, if there was one. An open question is whether we want to wait for all possible consoles or whether we can proceed with as few as one. David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, Apr 21, 2009 at 08:25:01PM +0100, Alan Cox wrote: > > Anybody want to try it? Just make it ignore any IO if there are no > > registered consoles. The patch shouldn't even be all that big, I suspect. > > It will work, but on its own it won't actually fix the problem people > have, which is wanting to wait for a real console to appear. Extending it > to sleep (if not O_NDELAY) and loop back through the list when the list > changes would however do the trick, that or a tty device that buffers > then spews into the real device when it appears. > > Definitely the right path, and we almost have every tty device in > existance containing a struct tty_port, at which point it gets even > cleaner. > > The printk() console needs to buffer up data and replay it but we already > pretty much do what is needed even for vt consoles because the fb isn't > ready before the first printk. We're already good on printk, the size of log_buf is configurable and log_buf is dumped to each console as it gets registered. Even then, printk output is not an especially big issue since you have dmesg to get to anything you might have missed. Other the other hand, userspace output is not buffered and has the potential to be much larger. Any approach that buffers it risks either truncation or gobbling up memory. There is also the human factors issue that users will pretty much ignore printk output because they don't particularly understand it. They understand, and expect to see, the output they generate. I'm pretty sure they won't like for it to go missing under mysterious circumstances. David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, Apr 21, 2009 at 03:09:52PM -0400, Alan Stern wrote: > On Tue, 21 Apr 2009, David VomLehn wrote: > > > > If somebody would like to suggest a programming interface (a waitqueue > > > perhaps?) by which the USB hub driver could send a notification when it > > > becomes idle, I could implement it. > > > > I actually started the USB console stuff with exactly this approach, but > > switched to the approach that's out there. A minor drawback, which is > > probably obvious, is that you actually wait for some interval without > > getting anything to do before you think things are idle. > > Sorry, I don't understand. You've got a waitqueue, and you wake up to > try again every time a console device is registered. So if the console > device does exist, you'll find it as quickly as possible. There's a > problem only when no console device is ever registered. In that case > you want to stop waiting when all the devices present at boot time have > been probed (as opposed to waiting for the user to plug in a USB serial > device, for example). > > So then the problem becomes: How do you tell when all the USB devices > present at boot time have been probed? That's exactly what this new > interface is supposed to tell you. The current patch already uses a waitqueue and wakes up as soon as a console is registered, so that's the same. I agree that the other piece is determining when all USB devices at boot time have been probed. For this suggestion to work, two conditions must be met: 1. The USB hub driver becoming idle must indicate that every device has been probed. 2. The USB driver must become idle after every USB device has been probed. If both conditions are met, this is a superior to a timeout for determining that the console will not show up. It would surprise me a bit if the first condition was true. Still, if it is true that the USB hub driver will be idle for some interval I, where I is greater than the timeout we would otherwise use, it is still a better approach. There is one other possible gotcha to this approach. The code as I wrote it is bus-agnostic, i.e. it has no idea where the console is located. As far as I know, the long time to probe possible console devices only arises with USB. If this is not tree, we need to handle any other cases that can arise. > > But a bigger > > drawback is that you lose the ability to chose appropriate intervals for > > different classes of devices. > > Why do you need to choose any intervals at all? Just keep waiting > until you know there's no point waiting any longer. If you stop > waiting before then, you run the risk of missing a device that could > have worked. The question about appropriate intervals is that I need to wait for some devices, like consoles and network devices, but not all devices, like printers and cameras. There is no telling whether any two devices require the same interval when I am tuning it for my particular system. And if I have a USB console and no USB Ethernet device, I only want to wait for the console probe interval. > > So far, there appear to be three possible USB boot devices: consoles, > > network > > devices, and boot devices. > > Is that last supposed to be "disk drives containing root filesystems"? Yup. > > A system may not have all of these and so may not > > need to wait as long as a system with all of them. One of my goals is to > > preserve as much of the reduction in boot time as possible, even on systems > > that use USB devices that may or may not be plugged in. > > Let's take console devices as an example. If one is present then you > do want to wait until it is detected, instead of booting as quickly as > possible, right? Which implies that if one isn't present, you want to > wait until you _know_ that it's not present. Which means waiting all > all the devices present during boot have been probed. > > This approach should work fine with USB consoles and network devices; > it's not so easy to implement for USB disk drives. So let's not worry > about them. I'm kinda flexible about whether all possible consoles show up; the patch presently only waits for a console to be identified as the "preferred" console. This gets the system going as soon as you have some place to write output, but I won't argue with anyone who says we need to wait for all possible consoles. > Now the only drawback I can see would crop up if some device takes a > very long time to probe (perhaps because of errors and retries). If > there's no other console device, it could slow down the boot procedure > quite a lot. But there doesn't appear to be any logical alternative, > given your goals as stated above. If there is a way to guarantee that we are done with the probing, I'm all for using that. Will waiting for the USB hub driver to be idle do this? > Alan Stern David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majo
Re: [ltt-dev] [PATCH] nfs: add support for splice writes
On Apr 21, 2009, at 1:35 PM, Trond Myklebust wrote:
On Tue, 2009-04-21 at 10:48 -0400, Christoph Hellwig wrote:
On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
+static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
+struct file *filp, loff_t *ppos,
+size_t count, unsigned int flags)
+{
+ struct dentry *dentry = filp->f_path.dentry;
+
+ dprintk("NFS splice_write(%s/%s, %...@%lu)\n",
+ dentry->d_parent->d_name.name, dentry->d_name.name,
+ (unsigned long) count, (unsigned long long) *ppos);
+
+ return generic_file_splice_write(pipe, filp, ppos, count, flags);
+}
+
You need all calls from nfs_file_write, too:
- most importantly the nfs_revalidate_file_size for O_APPEND
Isn't O_APPEND illegal for splice_write()? It looks like it is from a
quick perusal of do_splice_from().
- the nfs_do_fsync for sync writes
generic_file_splice_write() calls generic_osync_inode(), which should
ensure sync writes even with NFS.
The one thing it won't do is propagate NFS write errors back to the
caller. If we do care about this, then we should certainly test for
nfs_need_sync_write() and then call nfs_do_fsync() (see
nfs_file_write()).
- probably the stats increment
We should talk to Chuck about this.
I don't know much about the characteristics of splice writes, so you
can do one of two things:
1. Create a separate BYTESWRITTEN counter for these
2. Lump them into NORMALBYTESWRITTEN if these are effectively cached
writes.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
> > failing to open it, why can't we make __tty_open() give you a dummy tty > > driver which is basically equivalent to /dev/null? And then 'replace' it > > with the real console driver if/when that later gets registered? The > > latter will be a high-caffeine job, but surely not impossible? > > This sounds like a good option. Don't confuse "/dev/console" and "the console device" in printk terms. The two are not the same thing and the latter is subject to stuff like redirection. > thing, but it should be possible to just do something like > > static struct tty_driver console_driver; No - a console device can fail to open so you need to try the next one in that situation. Some platforms use this feature. > Anybody want to try it? Just make it ignore any IO if there are no > registered consoles. The patch shouldn't even be all that big, I suspect. It will work, but on its own it won't actually fix the problem people have, which is wanting to wait for a real console to appear. Extending it to sleep (if not O_NDELAY) and loop back through the list when the list changes would however do the trick, that or a tty device that buffers then spews into the real device when it appears. Definitely the right path, and we almost have every tty device in existance containing a struct tty_port, at which point it gets even cleaner. The printk() console needs to buffer up data and replay it but we already pretty much do what is needed even for vt consoles because the fb isn't ready before the first printk. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 21 Apr 2009, David VomLehn wrote: > > If somebody would like to suggest a programming interface (a waitqueue > > perhaps?) by which the USB hub driver could send a notification when it > > becomes idle, I could implement it. > > I actually started the USB console stuff with exactly this approach, but > switched to the approach that's out there. A minor drawback, which is > probably obvious, is that you actually wait for some interval without > getting anything to do before you think things are idle. Sorry, I don't understand. You've got a waitqueue, and you wake up to try again every time a console device is registered. So if the console device does exist, you'll find it as quickly as possible. There's a problem only when no console device is ever registered. In that case you want to stop waiting when all the devices present at boot time have been probed (as opposed to waiting for the user to plug in a USB serial device, for example). So then the problem becomes: How do you tell when all the USB devices present at boot time have been probed? That's exactly what this new interface is supposed to tell you. > But a bigger > drawback is that you lose the ability to chose appropriate intervals for > different classes of devices. Why do you need to choose any intervals at all? Just keep waiting until you know there's no point waiting any longer. If you stop waiting before then, you run the risk of missing a device that could have worked. > So far, there appear to be three possible USB boot devices: consoles, network > devices, and boot devices. Is that last supposed to be "disk drives containing root filesystems"? > A system may not have all of these and so may not > need to wait as long as a system with all of them. One of my goals is to > preserve as much of the reduction in boot time as possible, even on systems > that use USB devices that may or may not be plugged in. Let's take console devices as an example. If one is present then you do want to wait until it is detected, instead of booting as quickly as possible, right? Which implies that if one isn't present, you want to wait until you _know_ that it's not present. Which means waiting all all the devices present during boot have been probed. This approach should work fine with USB consoles and network devices; it's not so easy to implement for USB disk drives. So let's not worry about them. Now the only drawback I can see would crop up if some device takes a very long time to probe (perhaps because of errors and retries). If there's no other console device, it could slow down the boot procedure quite a lot. But there doesn't appear to be any logical alternative, given your goals as stated above. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
Tue, Apr 21, 2009 at 10:37:41AM -0700, Linus Torvalds wrote: > > > On Tue, 21 Apr 2009, David VomLehn wrote: > > > > What in the world are users going to do when they see a message about > > output being lost? There is no way to recover the data and no way to > > prevent it in the future. I don't think this is a good approach. > > Sure there is. The console messages are saved too, so doing 'dmesg' will > get you all the data that was generated before the console went on-line. > > We _already_ lose data in that sense (although we could replay it for the > first console connected - maybe we even do, I'm too lazy to check). There are two different things coming out on the console, kernel log buffer messages and userspace output to /dev/console. Kernel log buffer output is replayed for each console as it connects. There might be quite a bit of it, but it is pretty much the same from boot to boot, so the guy working on the kernel, me, can tune the size of log_buf pretty easily. This is not the problem. The problem is the userspace output to /dev/console. I work in the embedded space and my box does not simply throw up a few windows and wait placidly for the user to do something. Instead, it immediately starts running a whole bunch of software with a whole bunch of startup messages. In short order, I am running over 300 threads. I have no control over how much output comes out, I have no idea how much kernel memory to allocate for this, and I'm quote sure it's enough that I wouldn't want to waste that much space even if I did. No matter what, this looks like we'd need a new tunable for the size. And then, what happens if I *never* get a console, because one isn't plugged in? This happens a lot in the embedded world. How long am I supposed to keep around this big chunk of buffered data? Sounds like I need *another* tunable. Yuck. > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 21 Apr 2009, David VomLehn wrote: > > What in the world are users going to do when they see a message about > output being lost? There is no way to recover the data and no way to > prevent it in the future. I don't think this is a good approach. Sure there is. The console messages are saved too, so doing 'dmesg' will get you all the data that was generated before the console went on-line. We _already_ lose data in that sense (although we could replay it for the first console connected - maybe we even do, I'm too lazy to check). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 2009-04-21 at 10:29 -0700, David VomLehn wrote: > On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: > ... > > The kernel output is going to be spewed when a console registers with > > CON_PRINTBUFFER anyway, and if we printk a warning about userspace > > console output being lost, that ought to be good enough to notify the > > user that something may have been lost. For bonus points, we could even > > make that 'dummy' tty driver buffer a limited amount of userspace > > output, maybe. > > What in the world are users going to do when they see a message about > output being lost? There is no way to recover the data and no way to > prevent it in the future. I don't think this is a good approach. > > Remember, even though the previous functionality of USB consoles was, in > theory, less reliable than it appeared, it actually has been working well > for years. Thus, tossing output will count as a regression for most of the > world. So implement a small amount of buffering, as I suggested, and it should be sufficient to cover the cases that were only working before by blind luck anyway. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 21 Apr 2009, David Woodhouse wrote: > > We can provide un-hooked-up /dev/console though. Rather than just > failing to open it, why can't we make __tty_open() give you a dummy tty > driver which is basically equivalent to /dev/null? And then 'replace' it > with the real console driver if/when that later gets registered? The > latter will be a high-caffeine job, but surely not impossible? This sounds like a good option. Right now we look through all the console_drivers at open time in that struct tty_driver *console_device(int *index) thing, but it should be possible to just do something like static struct tty_driver console_driver; and then just make "console_device()" always return _that_ tty driver instead. Then, we could make that console_device tty driver just at run-time spread the IO to the proper device(s), rather than fix the one particular device at "open()" time. [ Actually, looking closer we should not use that particular name: we already have something called a "console_driver" which is really the "current VT" driver. So we should call it 'system_console_device' or something, but you get the idea. ] Anybody want to try it? Just make it ignore any IO if there are no registered consoles. The patch shouldn't even be all that big, I suspect. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ltt-dev] [PATCH] nfs: add support for splice writes
On Tue, 2009-04-21 at 10:48 -0400, Christoph Hellwig wrote:
> On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
> > +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> > +struct file *filp, loff_t *ppos,
> > +size_t count, unsigned int flags)
> > +{
> > + struct dentry *dentry = filp->f_path.dentry;
> > +
> > + dprintk("NFS splice_write(%s/%s, %...@%lu)\n",
> > + dentry->d_parent->d_name.name, dentry->d_name.name,
> > + (unsigned long) count, (unsigned long long) *ppos);
> > +
> > + return generic_file_splice_write(pipe, filp, ppos, count, flags);
> > +}
> > +
>
> You need all calls from nfs_file_write, too:
>
> - most importantly the nfs_revalidate_file_size for O_APPEND
Isn't O_APPEND illegal for splice_write()? It looks like it is from a
quick perusal of do_splice_from().
> - the nfs_do_fsync for sync writes
generic_file_splice_write() calls generic_osync_inode(), which should
ensure sync writes even with NFS.
The one thing it won't do is propagate NFS write errors back to the
caller. If we do care about this, then we should certainly test for
nfs_need_sync_write() and then call nfs_do_fsync() (see
nfs_file_write()).
> - probably the stats increment
We should talk to Chuck about this.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: ... > The kernel output is going to be spewed when a console registers with > CON_PRINTBUFFER anyway, and if we printk a warning about userspace > console output being lost, that ought to be good enough to notify the > user that something may have been lost. For bonus points, we could even > make that 'dummy' tty driver buffer a limited amount of userspace > output, maybe. What in the world are users going to do when they see a message about output being lost? There is no way to recover the data and no way to prevent it in the future. I don't think this is a good approach. Remember, even though the previous functionality of USB consoles was, in theory, less reliable than it appeared, it actually has been working well for years. Thus, tossing output will count as a regression for most of the world. > If userspace cares, let _it_ wait, by using an ioctl to see what tty > device it's _really_ attached to. I have a notion, perhaps misguided, that userspace *always* cares about seeing all the output they have generated. I have no objection to a userspace solution, in the long run, but such an approach represents a significantly different approach to constructing boot filesystems and we need a transitional period. In the interim, let's get things working as they were. > David WoodhouseOpen Source Technology Centre David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 2009-04-21 at 00:13 -0700, David Brownell wrote: > > Stepping back a moment from "how" to make sure "what" is agreed on. > > I think I see three scenarios here: > > - Classic PC or server, where there's a meaningful console; > > - Deeply embedded systems, where there isn't; > > - Development stages of "deeply embedded", where there *may* be one. > > If that's correct, then async_synchronize() isn't a full answer... > > I think a fair number of cases can be papered over with a serial > console with no hardware flow control, which isn't hooked up to > anything. Maybe the board needs a test/development jig to get one; > without it, the "console" bits spill out into the aether. Linux > can dump bits to ttyS0, which will act like /dev/null. > > But the problem case here seems to be one where such un-hooked-up > serial ports are not realistic options. Which is why the regression > in USB console functionality has been troublesome. We can provide un-hooked-up /dev/console though. Rather than just failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver if/when that later gets registered? The latter will be a high-caffeine job, but surely not impossible? The kernel output is going to be spewed when a console registers with CON_PRINTBUFFER anyway, and if we printk a warning about userspace console output being lost, that ought to be good enough to notify the user that something may have been lost. For bonus points, we could even make that 'dummy' tty driver buffer a limited amount of userspace output, maybe. If userspace cares, let _it_ wait, by using an ioctl to see what tty device it's _really_ attached to. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
> If somebody would like to suggest a programming interface (a waitqueue > perhaps?) by which the USB hub driver could send a notification when it > becomes idle, I could implement it. I actually started the USB console stuff with exactly this approach, but switched to the approach that's out there. A minor drawback, which is probably obvious, is that you actually wait for some interval without getting anything to do before you think things are idle. But a bigger drawback is that you lose the ability to chose appropriate intervals for different classes of devices. So far, there appear to be three possible USB boot devices: consoles, network devices, and boot devices. A system may not have all of these and so may not need to wait as long as a system with all of them. One of my goals is to preserve as much of the reduction in boot time as possible, even on systems that use USB devices that may or may not be plugged in. > Alan Stern David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote: > > * Jamie Lokier wrote: > > > Ingo Molnar wrote: ... > > > What i'm saying is: instead of "wait 2000 msecs, maybe it works > > > out" hack, there should be a proper sleep+event based approach > > > to the same. With perhaps a _timeout_ for the "no console > > > arrived" negative case as well. (which timeout can be set to > > > zero in the "I _know_ there's no console around".) > > > > Isn't the proposed code doing exactly that? It sleeps waiting for > > a console, with a timeout of X msecs. If a console arrives before > > that, doesn't it wake immediately? > > Yes - except that the timeout is aspecific. I.e. we'll time out even > if the delay happens not due to a device arriving too late (or not > arriving at all), but due to some earlier init step taking an > unexpectedly long time. I agree, but this is also a pretty good description of why things actually worked before--it just so happened that work intervening between starting USB enumeration and the opening of /dev/console was long enough that USB serial devices were initialized. So, no, it's not good. But it's a pretty close equivalent to previous behavior. That being said, I'm also thinking that the timeout interval should start when bus initialization is started. The point between the start of USB initialization and when a particular device is initialized should be, as a practical matter and for a particular hardware configuration, more or less constant, and so more predictable for users. Basing the wait interval from the start of bus initialization has the additional advantage that we can also implement similar timers, such as one for network devices, off the same base time. Since the ip= kernel parameter is similarly broken, I've been looking at what it would take to get it working again, too. Or at least, with deference to the constraints of USB and acknowledging the importance of luck, working as well as it used to. > Also, if we end up doing this - the patch, as proposed right now, > appears to add a default 1000 msecs sleep to every __tty_open() > call: > > +config PRINTK_CONSOLE_WAIT > + int "Default number of milliseconds to wait for console device" > + default 1000 > > Does this only delay init during a console-less bootup - or are > there other later apps that might trigger the delay? Sleeping and polling for an event, rather than using a suitable notification primitive, causes me existential anguish. Seriously, I *hate* code like that and systems that make you do such brutish things. Linux is not one of those throwbacks, so as soon as a console shows up, we continue. Thus, we only wait the whole interval if the console device is very slow to initialize or if there is no console device, at all. -- David VomLehn -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ltt-dev] [PATCH] nfs: add support for splice writes
On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> + struct file *filp, loff_t *ppos,
> + size_t count, unsigned int flags)
> +{
> + struct dentry *dentry = filp->f_path.dentry;
> +
> + dprintk("NFS splice_write(%s/%s, %...@%lu)\n",
> + dentry->d_parent->d_name.name, dentry->d_name.name,
> + (unsigned long) count, (unsigned long long) *ppos);
> +
> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
> +}
> +
You need all calls from nfs_file_write, too:
- most importantly the nfs_revalidate_file_size for O_APPEND
- the nfs_do_fsync for sync writes
- probably the stats increment
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
> +config PRINTK_CONSOLE_WAIT > + int "Default number of milliseconds to wait for console device" > + default 1000 > > Does this only delay init during a console-less bootup - or are > there other later apps that might trigger the delay? The console proper needs to be event based not timeout hacks. Can we please fix this stuff properly ? To start with there is no reason that the USB console can't implement a "maybe we have hardware, maybe I buffer 64K until it shows up" behaviour and bind to hardware as and when USB serial devices get inserted. We do much of this for the VT drivers so we save messages before PCI and fb come up. The timeout wait proposed is also wrong I agree. Take a timestamp at the point we are ready to mount the root fs, any delays on root mount, console appearance etc should then be tested against this timestamp not as delays versus some undefined later event. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 21 Apr 2009, Jamie Lokier wrote: > Ingo Molnar wrote: > > * Arjan van de Ven wrote: > > > But more importantly... USB *CANNOT* do this fundamental > > > operation. USB does not have the capability to know when you have > > > seen all devices that are connected. Devices just show up a random > > > amount of time after you turn the power on for the bus there's > > > no "and now we've seen all" operation. > > > > Yes - and this is fundamentally true of any hotplug bus design. > > It's not fundamental, for devices you know are plugged in at boot. > All it takes is for the bus to support a synchronous "enumerate all" > procedure. That _could_ involve a timeout, but there are better ways. > But not for USB. Is that last sentence necessarily true? I suppose it is true that a USB device isn't obligated to make its presence on the bus known immediately, but nevertheless, most of them do. In theory we could add code to the USB subsystem to detect when the hub driver has become idle and therefore all devices that were initially plugged in have been probed. That probably would work for solving the console problem. Storage devices present additional problems, however: When usb-storage discovers a device, it generally delays a while before scanning it. (The default delay is 5 seconds, but it is adjustable by a module parameter.) And then when the scanning function is called, the SCSI subsystem turns it into an asynchronous request -- that's why the kernel log usually says "usb-storage: device scan complete" before the scan has in fact begun. So I don't know about determining when all USB mass-storage devices have been detected, but USB serial devices should be practical. If somebody would like to suggest a programming interface (a waitqueue perhaps?) by which the USB hub driver could send a notification when it becomes idle, I could implement it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
* Jamie Lokier wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven wrote:
> > > But more importantly... USB *CANNOT* do this fundamental
> > > operation. USB does not have the capability to know when you have
> > > seen all devices that are connected. Devices just show up a random
> > > amount of time after you turn the power on for the bus there's
> > > no "and now we've seen all" operation.
> >
> > Yes - and this is fundamentally true of any hotplug bus design.
>
> It's not fundamental, for devices you know are plugged in at boot.
> All it takes is for the bus to support a synchronous "enumerate
> all" procedure. That _could_ involve a timeout, but there are
> better ways. But not for USB.
>
> > What i'm saying is: instead of "wait 2000 msecs, maybe it works
> > out" hack, there should be a proper sleep+event based approach
> > to the same. With perhaps a _timeout_ for the "no console
> > arrived" negative case as well. (which timeout can be set to
> > zero in the "I _know_ there's no console around".)
>
> Isn't the proposed code doing exactly that? It sleeps waiting for
> a console, with a timeout of X msecs. If a console arrives before
> that, doesn't it wake immediately?
Yes - except that the timeout is aspecific. I.e. we'll time out even
if the delay happens not due to a device arriving too late (or not
arriving at all), but due to some earlier init step taking an
unexpectedly long time.
> > Do you see the fundamental design difference between the two
> > solutions?
>
> The only difference I see is: If you asked for a USB console, the
> timeout should begin relative to when the USB host driver kicks
> the bus, not the first /dev/console open.
>
> Conceptually the timeout is a USB characteristic, not a generic
> console one.
>
> For other (non-USB) devices which might take a while to
> initialise, it should work as you describe. E.g. an ethernet TCP
> console should register ("i'm trying to give you a console")
> followed by ("got it") or ("failed, carry on without me").
I guess we could live with this one too but still it feels wrong to
me. It would be much better to push the decision to time out into
individual console drivers.
Also, if we end up doing this - the patch, as proposed right now,
appears to add a default 1000 msecs sleep to every __tty_open()
call:
+config PRINTK_CONSOLE_WAIT
+ int "Default number of milliseconds to wait for console device"
+ default 1000
Does this only delay init during a console-less bootup - or are
there other later apps that might trigger the delay?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
Ingo Molnar wrote:
> * Arjan van de Ven wrote:
> > But more importantly... USB *CANNOT* do this fundamental
> > operation. USB does not have the capability to know when you have
> > seen all devices that are connected. Devices just show up a random
> > amount of time after you turn the power on for the bus there's
> > no "and now we've seen all" operation.
>
> Yes - and this is fundamentally true of any hotplug bus design.
It's not fundamental, for devices you know are plugged in at boot.
All it takes is for the bus to support a synchronous "enumerate all"
procedure. That _could_ involve a timeout, but there are better ways.
But not for USB.
> What i'm saying is: instead of "wait 2000 msecs, maybe it works out"
> hack, there should be a proper sleep+event based approach to the
> same. With perhaps a _timeout_ for the "no console arrived" negative
> case as well. (which timeout can be set to zero in the "I _know_
> there's no console around".)
Isn't the proposed code doing exactly that? It sleeps waiting for a
console, with a timeout of X msecs. If a console arrives before that,
doesn't it wake immediately?
> Do you see the fundamental design difference between the two
> solutions?
The only difference I see is: If you asked for a USB console, the
timeout should begin relative to when the USB host driver kicks the
bus, not the first /dev/console open.
Conceptually the timeout is a USB characteristic, not a generic
console one.
For other (non-USB) devices which might take a while to initialise, it
should work as you describe. E.g. an ethernet TCP console should
register ("i'm trying to give you a console") followed by ("got it")
or ("failed, carry on without me").
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
* Arjan van de Ven wrote: > On Tue, 21 Apr 2009 08:43:46 +0200 > Ingo Molnar wrote: > > > The proper approach would be to use one of the async_synchronize*() > > facilities in kernel/async.c to properly order the opening of the > > console with device init. > > Unfortunately this is not the answer. > > First of all, USB does not use the async_* infrastructure, so it does > not do anything. [ Of course it does not. Two kernel cycles ago nothing had any async infrastructure ;-) We barely have any use of it today. But cases like this are the way to extend its use. ] > But more importantly... USB *CANNOT* do this fundamental > operation. USB does not have the capability to know when you have > seen all devices that are connected. Devices just show up a random > amount of time after you turn the power on for the bus there's > no "and now we've seen all" operation. Yes - and this is fundamentally true of any hotplug bus design. Nevertheless the wish has been expressed to wait for such a device to become available, in this very thread we are discussing. What i'm saying is: instead of "wait 2000 msecs, maybe it works out" hack, there should be a proper sleep+event based approach to the same. With perhaps a _timeout_ for the "no console arrived" negative case as well. (which timeout can be set to zero in the "I _know_ there's no console around".) Do you see the fundamental design difference between the two solutions? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Tue, 21 Apr 2009 08:43:46 +0200 Ingo Molnar wrote: > The proper approach would be to use one of the async_synchronize*() > facilities in kernel/async.c to properly order the opening of the > console with device init. Unfortunately this is not the answer. First of all, USB does not use the async_* infrastructure, so it does not do anything. But more importantly... USB *CANNOT* do this fundamental operation. USB does not have the capability to know when you have seen all devices that are connected. Devices just show up a random amount of time after you turn the power on for the bus there's no "and now we've seen all" operation. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
* David Brownell wrote: > On Monday 20 April 2009, Ingo Molnar wrote: > > > The proper approach would be to use one of the > > async_synchronize*() facilities in kernel/async.c to properly > > order the opening of the console with device init. > > Stepping back a moment from "how" to make sure "what" is agreed > on. > > I think I see three scenarios here: > > - Classic PC or server, where there's a meaningful console; > > - Deeply embedded systems, where there isn't; > > - Development stages of "deeply embedded", where there *may* be >one. > > If that's correct, then async_synchronize() isn't a full answer... > > I think a fair number of cases can be papered over with a serial > console with no hardware flow control, which isn't hooked up to > anything. Maybe the board needs a test/development jig to get > one; without it, the "console" bits spill out into the aether. > Linux can dump bits to ttyS0, which will act like /dev/null. > > But the problem case here seems to be one where such un-hooked-up > serial ports are not realistic options. Which is why the > regression in USB console functionality has been troublesome. > > Is that correct? Not sure i understand the complication. The practical issue addressed by this particular patch i've replied to is that if /dev/console is sys_open()-ed by an app "too early", an error code is returned and subsequently user-space (and all its child tasks) remain console-less. Whether the console has flow control or not is immaterial. Initialization sequence ordering details should be transparent as far as sys_open() of a console is concerned. If there is _no console_, then obviously there's nothing to wait for and the async wait will succeed immediately. The console driver still returns an error on sys_open() but that is expected behavior. The solution proposed in the patch i'm replying to is a boot flag that causes the kernel to wait N milliseconds. This is incorrect and wrong on several levels. If the console can be initialized via a proper handshake that should be exposed precisely - we should not wait neither longer nor shorter than needed. _If_ there's no proper handshake and a magic delay is needed (because there's some hardware-internal delay needed at init time) before the console can be used then that should be in the console driver itself and the async-wait will wait for that automatically. But never should we have delays like this in generic code. Regardless of embedded versus server versus desktop issues. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
On Monday 20 April 2009, Ingo Molnar wrote: > The proper approach would be to use one of the async_synchronize*() > facilities in kernel/async.c to properly order the opening of the > console with device init. Stepping back a moment from "how" to make sure "what" is agreed on. I think I see three scenarios here: - Classic PC or server, where there's a meaningful console; - Deeply embedded systems, where there isn't; - Development stages of "deeply embedded", where there *may* be one. If that's correct, then async_synchronize() isn't a full answer... I think a fair number of cases can be papered over with a serial console with no hardware flow control, which isn't hooked up to anything. Maybe the board needs a test/development jig to get one; without it, the "console" bits spill out into the aether. Linux can dump bits to ttyS0, which will act like /dev/null. But the problem case here seems to be one where such un-hooked-up serial ports are not realistic options. Which is why the regression in USB console functionality has been troublesome. Is that correct? - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
