* Re: [Patch] Wait for console to become available, ver 3
From: David VomLehn @ 2009-04-20 22:29 UTC (permalink / raw)
To: Alan Stern
Cc: Andrew Morton, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.44L0.0904201744410.6832-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
> Personally, I'm in favor of adding a boot parameter. Things could be
> simplified slightly by treating a negative value (or a missing value)
> as indicating an infinite timeout; then only one new parameter would be
> needed instead of two.
I'm allergic to the idea of a user interface using negative one to mean
infinity. It's an bizzare idea that makes sense only to programming
wankers. Such as ourselves. Having a missing value mean infinitity is a
not whole lot better.
I do agree with the idea of adding one boot parameter rather than two. How
about keeping the consoledelay parameter, but allow it to either take a
string, such as "forever", or an integer, which is the number of milliseconds
to delay? I think that will make sense to a lot more people.
Note that, as far as the implementation goes, using a -1 to mean an infinite
wait may very well make sense. I just don't think it makes sense where decent
people can see it.
--
David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Andrew Morton @ 2009-04-20 22:14 UTC (permalink / raw)
To: Alan Stern
Cc: dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.44L0.0904201744410.6832-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Mon, 20 Apr 2009 17:51:16 -0400 (EDT)
Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Mon, 20 Apr 2009, Andrew Morton wrote:
>
> > If we want b) then how to do it?
> >
> > One possibility: the initcalls have been completed when init_post() is
> > called. How about: if one of those initcalls will be asynchronously
> > registering a console, it should inform the console layer about this.
> > It should call the new i_will_be_adding_a_console_soon() function
> > within its initcall. The console subsystem will remember this, and we
> > can cause init_post() to block until that registration has occurred.
> >
> > We'll need to be able to handle errors, and we'll need to be able to
> > handle the case where the initcall function isn't sure whether or not
> > it will be registering a console. So there will also need to be an
> > oops_im_not_adding_a_console_after_all() function, which will withdraw
> > the effects of i_will_be_adding_a_console_soon().
> >
> > Which means that i_will_be_adding_a_console_soon() will need to return
> > a handle for the oops_im_not_adding_a_console_after_all() caller to
> > pass.
> >
> > If init_post() is currently blocked awaiting the arrival of the
> > console, oops_im_not_adding_a_console_after_all() will unblock
> > init_post() if there are no more potential console registrations
> > pending, and inti_post()'s attempt to open a console will fail.
> >
> >
> > Or something like that?
>
> What if a subsystem simply doesn't know in advance whether or not it's
> going to register a console? Or doesn't know when it has finished
> probing all devices (since a new device could be plugged in at any
> time)?
Fix it. It's trivial to make a sub-driver call back into a higher
layer to tell it that it registered a console. Or just do the
i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all()
calls from the layer which _does_ know.
> Not to mention that this scheme appears more complicated than the one
> it's intended to replace... although it doesn't have any boot-line
> parameters.
It isn't very complicated.
Yes, a boot parameter is "simple" to inplement. But it's ghastly from
a usability POV. Especially if you care about boot times. For how
long do you delay? The user has to experiment with different delays
until he finds the magic number. Then he adds 10% and waits for the
inevitable failure reports to come in.
It's much better to just get it right, even if that makes it more
"complex".
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Alan Stern @ 2009-04-20 21:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: David VomLehn, linux-kernel, linux-embedded, linux-usb
In-Reply-To: <20090420143010.697c7380.akpm@linux-foundation.org>
On Mon, 20 Apr 2009, Andrew Morton wrote:
> If we want b) then how to do it?
>
> One possibility: the initcalls have been completed when init_post() is
> called. How about: if one of those initcalls will be asynchronously
> registering a console, it should inform the console layer about this.
> It should call the new i_will_be_adding_a_console_soon() function
> within its initcall. The console subsystem will remember this, and we
> can cause init_post() to block until that registration has occurred.
>
> We'll need to be able to handle errors, and we'll need to be able to
> handle the case where the initcall function isn't sure whether or not
> it will be registering a console. So there will also need to be an
> oops_im_not_adding_a_console_after_all() function, which will withdraw
> the effects of i_will_be_adding_a_console_soon().
>
> Which means that i_will_be_adding_a_console_soon() will need to return
> a handle for the oops_im_not_adding_a_console_after_all() caller to
> pass.
>
> If init_post() is currently blocked awaiting the arrival of the
> console, oops_im_not_adding_a_console_after_all() will unblock
> init_post() if there are no more potential console registrations
> pending, and inti_post()'s attempt to open a console will fail.
>
>
> Or something like that?
What if a subsystem simply doesn't know in advance whether or not it's
going to register a console? Or doesn't know when it has finished
probing all devices (since a new device could be plugged in at any
time)?
Not to mention that this scheme appears more complicated than the one
it's intended to replace... although it doesn't have any boot-line
parameters.
Personally, I'm in favor of adding a boot parameter. Things could be
simplified slightly by treating a negative value (or a missing value)
as indicating an infinite timeout; then only one new parameter would be
needed instead of two.
Alan Stern
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Andrew Morton @ 2009-04-20 21:30 UTC (permalink / raw)
To: David VomLehn; +Cc: linux-kernel, linux-embedded, linux-usb
In-Reply-To: <20090417213148.GA27825@cuplxvomd02.corp.sa.net>
On Fri, 17 Apr 2009 14:31:48 -0700
David VomLehn <dvomlehn@cisco.com> wrote:
> Parallelization to improve boot times has been successful enough that race
> conditions now exist between the init_post() open of /dev/console and
> initialization of the console device. When this occurs, opening /dev/console
> fails and any applications inherited from init have no standard in/out/error
> devices. This is expected behavior if no console device is available, but
> quite unfortunate in the case where the console is just a bit slow waking up.
>
> Some buses, such as USB, offer no guarantees about how long it takes to
> discover devices, so there is no reliable way to distinguish between a missing
> console and a slow one. The pragmatic approach taken in this patch is to
> wait for a while to see if a console shows up, and just go on if it doesn't.
> The default delay is 1000 msec (1 second).
>
> There are two new command line parameters:
> consolewait Wait forever for a console to be registered
> consoledelay=msec Use the given number of milliseconds as the delay
> interval instead of the default
This is all pretty nasty, isn't it?
Let's step back for a bit from any implementation and ask "what is the
ideal behaviour"? I think it's one of
a) we permit init_post()'s open() to succeed. Console output is
buffered by the kernel (could be in the printk log_buf). When the
initial console is eventually registered, we flush all the queued
characters into it.
b) we block in init_post(), waiting for the initial console to
become available.
I think b) is better. Simpler, safer, less likely for information loss
if the kernel were to crash in that delay window.
Am I right? Did I miss any options?
If we want b) then how to do it?
One possibility: the initcalls have been completed when init_post() is
called. How about: if one of those initcalls will be asynchronously
registering a console, it should inform the console layer about this.
It should call the new i_will_be_adding_a_console_soon() function
within its initcall. The console subsystem will remember this, and we
can cause init_post() to block until that registration has occurred.
We'll need to be able to handle errors, and we'll need to be able to
handle the case where the initcall function isn't sure whether or not
it will be registering a console. So there will also need to be an
oops_im_not_adding_a_console_after_all() function, which will withdraw
the effects of i_will_be_adding_a_console_soon().
Which means that i_will_be_adding_a_console_soon() will need to return
a handle for the oops_im_not_adding_a_console_after_all() caller to
pass.
If init_post() is currently blocked awaiting the arrival of the
console, oops_im_not_adding_a_console_after_all() will unblock
init_post() if there are no more potential console registrations
pending, and inti_post()'s attempt to open a console will fail.
Or something like that?
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Suresh Jayaraman @ 2009-04-20 15:47 UTC (permalink / raw)
To: Trond Myklebust
Cc: Masahiro Tamori, Mathieu Desnoyers, linux-nfs, ltt-dev, LKML,
linux-embedded, Peter Zijlstra
In-Reply-To: <1240237274.13636.9.camel@heimdal.trondhjem.org>
Trond Myklebust wrote:
> On Mon, 2009-04-20 at 18:08 +0530, Suresh Jayaraman wrote:
>> Trond Myklebust wrote:
>>> On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote:
>>>> Hi Trond,
>>>>
>>>> Do you think this patch is OK? Can this be considered for merging?
>>>>>>>> +
>>>>>>>> + if (IS_SWAPFILE(inode)) {
>>>>>>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
>>>>>>>> + "file!\n");
>>>>>>>> + return -EBUSY;
>>>>>>>> + }
>>> I don't know that we really need this. We should sweep through the NFS
>>> code and kill all those IS_SWAPFILE() thingys. Or at least #define
>>> IS_SWAPFILE(a) (0)
>>> ...
>> Hmm.. I'm not sure whether we should kill them now. I think originally,
>> these were added keeping in mind the future NFS swap support. Given that
>> the recent work from Peterz Zilstra on "Swap over NFS" and multiple
>> iterations/review on the same, I think those patches will eventually get
>> merged sooner or later. Perhaps, it's a good idea to #define
>> IS_SWAPFILE(a) 0 than killing them entirely..?
>
> Why are they needed at all? AFAICS, other filesystems check IS_SWAPFILE
> when truncating a file, but don't litter their code with all these weird
> checks for writing, reading, etc.
Yes, except for afs other filesystems seem to check only during
truncation.
> It's not as if these checks can stop a determined privileged person from
> writing to the swapfile anyway. All they have to do is go to another
> client or write directly to the file on the server...
>
Make sense.
Here is the trimmed version. I think the dprink could be retained
for debugging issues, if any.
Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
---
fs/nfs/file.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 5a97bcf..6dfe7df 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -48,6 +48,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
size_t count, unsigned int flags);
static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
unsigned long nr_segs, loff_t pos);
+static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
+ struct file *filp, loff_t *ppos,
+ size_t count, unsigned int flags);
static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
unsigned long nr_segs, loff_t pos);
static int nfs_file_flush(struct file *, fl_owner_t id);
@@ -73,6 +76,7 @@ const struct file_operations nfs_file_operations = {
.lock = nfs_lock,
.flock = nfs_flock,
.splice_read = nfs_file_splice_read,
+ .splice_write = nfs_file_splice_write,
.check_flags = nfs_check_flags,
.setlease = nfs_setlease,
};
@@ -587,6 +591,19 @@ out_swapfile:
goto out;
}
+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@%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);
+}
+
static int do_getlk(struct file *filp, int cmd, struct file_lock *fl)
{
struct inode *inode = filp->f_mapping->host;
^ permalink raw reply related
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Trond Myklebust @ 2009-04-20 14:21 UTC (permalink / raw)
To: Suresh Jayaraman
Cc: Masahiro Tamori, Mathieu Desnoyers, linux-nfs, ltt-dev, LKML,
linux-embedded, Peter Zijlstra
In-Reply-To: <49EC6CB3.8080800@suse.de>
On Mon, 2009-04-20 at 18:08 +0530, Suresh Jayaraman wrote:
> Trond Myklebust wrote:
> > On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote:
> >> Hi Trond,
> >>
> >> Do you think this patch is OK? Can this be considered for merging?
> >>
> >> Thanks,
> >>
> >>>>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> >>>>>> index 90f292b..13d6a00 100644
> >>>>>> --- a/fs/nfs/file.c
> >>>>>> +++ b/fs/nfs/file.c
> >>>>>> @@ -47,6 +47,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
> >>>>>> size_t count, unsigned int flags);
> >>>>>> static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
> >>>>>> unsigned long nr_segs, loff_t pos);
> >>>>>> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> >>>>>> + struct file *filp, loff_t *ppos,
> >>>>>> + size_t count, unsigned int flags);
> >>>>>> static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
> >>>>>> unsigned long nr_segs, loff_t pos);
> >>>>>> static int nfs_file_flush(struct file *, fl_owner_t id);
> >>>>>> @@ -76,6 +79,7 @@ const struct file_operations nfs_file_operations = {
> >>>>>> .lock = nfs_lock,
> >>>>>> .flock = nfs_flock,
> >>>>>> .splice_read = nfs_file_splice_read,
> >>>>>> + .splice_write = nfs_file_splice_write,
> >>>>>> .check_flags = nfs_check_flags,
> >>>>>> .setlease = nfs_setlease,
> >>>>>> };
> >>>>>> @@ -550,6 +554,26 @@ out_swapfile:
> >>>>>> goto out;
> >>>>>> }
> >>>>>>
> >>>>>> +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;
> >>>>>> + struct inode *inode = dentry->d_inode;
> >>>>>> +
> >>>>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
> >>>>>> + dentry->d_parent->d_name.name, dentry->d_name.name,
> >>>>>> + (unsigned long) count, (unsigned long long) *ppos);
> >>>>>> +
> >>>>>> + if (IS_SWAPFILE(inode)) {
> >>>>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
> >>>>>> + "file!\n");
> >>>>>> + return -EBUSY;
> >>>>>> + }
> >
> > I don't know that we really need this. We should sweep through the NFS
> > code and kill all those IS_SWAPFILE() thingys. Or at least #define
> > IS_SWAPFILE(a) (0)
> > ...
>
> Hmm.. I'm not sure whether we should kill them now. I think originally,
> these were added keeping in mind the future NFS swap support. Given that
> the recent work from Peterz Zilstra on "Swap over NFS" and multiple
> iterations/review on the same, I think those patches will eventually get
> merged sooner or later. Perhaps, it's a good idea to #define
> IS_SWAPFILE(a) 0 than killing them entirely..?
Why are they needed at all? AFAICS, other filesystems check IS_SWAPFILE
when truncating a file, but don't litter their code with all these weird
checks for writing, reading, etc.
It's not as if these checks can stop a determined privileged person from
writing to the swapfile anyway. All they have to do is go to another
client or write directly to the file on the server...
Trond
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Suresh Jayaraman @ 2009-04-20 12:38 UTC (permalink / raw)
To: Trond Myklebust
Cc: Masahiro Tamori, Mathieu Desnoyers,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
ltt-dev-33AaDErTWvBVxDZ2/Zk0YoryAYyacSEB, LKML,
linux-embedded-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra
In-Reply-To: <1240230224.8073.6.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
Trond Myklebust wrote:
> On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote:
>> Hi Trond,
>>
>> Do you think this patch is OK? Can this be considered for merging?
>>
>> Thanks,
>>
>>>>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
>>>>>> index 90f292b..13d6a00 100644
>>>>>> --- a/fs/nfs/file.c
>>>>>> +++ b/fs/nfs/file.c
>>>>>> @@ -47,6 +47,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
>>>>>> size_t count, unsigned int flags);
>>>>>> static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
>>>>>> unsigned long nr_segs, loff_t pos);
>>>>>> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
>>>>>> + struct file *filp, loff_t *ppos,
>>>>>> + size_t count, unsigned int flags);
>>>>>> static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
>>>>>> unsigned long nr_segs, loff_t pos);
>>>>>> static int nfs_file_flush(struct file *, fl_owner_t id);
>>>>>> @@ -76,6 +79,7 @@ const struct file_operations nfs_file_operations = {
>>>>>> .lock = nfs_lock,
>>>>>> .flock = nfs_flock,
>>>>>> .splice_read = nfs_file_splice_read,
>>>>>> + .splice_write = nfs_file_splice_write,
>>>>>> .check_flags = nfs_check_flags,
>>>>>> .setlease = nfs_setlease,
>>>>>> };
>>>>>> @@ -550,6 +554,26 @@ out_swapfile:
>>>>>> goto out;
>>>>>> }
>>>>>>
>>>>>> +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;
>>>>>> + struct inode *inode = dentry->d_inode;
>>>>>> +
>>>>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
>>>>>> + dentry->d_parent->d_name.name, dentry->d_name.name,
>>>>>> + (unsigned long) count, (unsigned long long) *ppos);
>>>>>> +
>>>>>> + if (IS_SWAPFILE(inode)) {
>>>>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
>>>>>> + "file!\n");
>>>>>> + return -EBUSY;
>>>>>> + }
>
> I don't know that we really need this. We should sweep through the NFS
> code and kill all those IS_SWAPFILE() thingys. Or at least #define
> IS_SWAPFILE(a) (0)
> ...
Hmm.. I'm not sure whether we should kill them now. I think originally,
these were added keeping in mind the future NFS swap support. Given that
the recent work from Peterz Zilstra on "Swap over NFS" and multiple
iterations/review on the same, I think those patches will eventually get
merged sooner or later. Perhaps, it's a good idea to #define
IS_SWAPFILE(a) 0 than killing them entirely..?
Thanks,
>>>>>> +
>>>>>> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
>>>>>> +}
>>>>>> +
>>>>>> static int do_getlk(struct file *filp, int cmd, struct file_lock *fl)
>>>>>> {
>>>>>> struct inode *inode = filp->f_mapping->host;
>>>>>>
>
> Otherwise it looks fine...
>
>
>
--
Suresh Jayaraman
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Trond Myklebust @ 2009-04-20 12:23 UTC (permalink / raw)
To: Suresh Jayaraman
Cc: Masahiro Tamori, Mathieu Desnoyers, linux-nfs, ltt-dev, LKML,
linux-embedded
In-Reply-To: <49EC0A83.8060802@suse.de>
On Mon, 2009-04-20 at 11:09 +0530, Suresh Jayaraman wrote:
> Hi Trond,
>
> Do you think this patch is OK? Can this be considered for merging?
>
> Thanks,
>
> Masahiro Tamori wrote:
> > Hello Suresh and Mathieu,
> >
> > 2009/4/2 Suresh Jayaraman <sjayaraman@suse.de>:
> >> Mathieu Desnoyers wrote:
> >>> * Suresh Jayaraman (sjayaraman@suse.de) wrote:
> >>>> This patch attempts to add splice writes support. In essence, it just
> >>>> calls generic_file_splice_write() after doing a little sanity check.
> >>>> This would allow LTTng users that are using NFS to store trace data.
> >>>> There could be more applications that could be benefitted too.
> >>>>
> >>>> I have tested this using the Jens' test program and have found no
> >>>> real issues. The test program is inlined below:
> >>>>
> >>> There is just a small checkpatch nit that I'll fix directly in place in
> >>> the LTTng tree.
> >>>
> >>> WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
> >>> #93: FILE: fs/nfs/file.c:564:
> >>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
> >>>
> >>> total: 0 errors, 1 warnings, 42 lines checked
> >>>
> >> Yes, I noticed it. There are quite a few places in nfs code where we
> >> happened to use that (that doesn't imply that it shouldn't be fixed), so
> >> I thought it's OK.
> >>
> >>> That's great ! I'll pull it in the LTTng tree so my users can try it.
> >>> They currently cannot write LTTng traces to NFS mounts anyway.
> >> Yes, please report the test results. Would appreciate it very much.
> >>
> >>
> >> Thanks,
> >
> > Thank you for creating a patch !!
> >
> > I tested it, and it works fine.
> >
> > My environment is following,
> > LTTV 0.12.10
> > LTTng 0.100
> > LTT Control 0.65
> > Kernles 2.6.29
> >
> > LTTng version is old now, but the test is passed on ARM11 target.
> >
> > Furthermore, I run the splice test and the test is passed too.
> > The test code is copied from
> > http://kzk9.net/blog/2007/05/splice2.html
> > (Japanese page)
> >
> > Thanks all people who commented this issue.
> >
> > Best regards,
> > Masahiro Tamori
> >
> >>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> >>>> index 90f292b..13d6a00 100644
> >>>> --- a/fs/nfs/file.c
> >>>> +++ b/fs/nfs/file.c
> >>>> @@ -47,6 +47,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
> >>>> size_t count, unsigned int flags);
> >>>> static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
> >>>> unsigned long nr_segs, loff_t pos);
> >>>> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> >>>> + struct file *filp, loff_t *ppos,
> >>>> + size_t count, unsigned int flags);
> >>>> static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
> >>>> unsigned long nr_segs, loff_t pos);
> >>>> static int nfs_file_flush(struct file *, fl_owner_t id);
> >>>> @@ -76,6 +79,7 @@ const struct file_operations nfs_file_operations = {
> >>>> .lock = nfs_lock,
> >>>> .flock = nfs_flock,
> >>>> .splice_read = nfs_file_splice_read,
> >>>> + .splice_write = nfs_file_splice_write,
> >>>> .check_flags = nfs_check_flags,
> >>>> .setlease = nfs_setlease,
> >>>> };
> >>>> @@ -550,6 +554,26 @@ out_swapfile:
> >>>> goto out;
> >>>> }
> >>>>
> >>>> +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;
> >>>> + struct inode *inode = dentry->d_inode;
> >>>> +
> >>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
> >>>> + dentry->d_parent->d_name.name, dentry->d_name.name,
> >>>> + (unsigned long) count, (unsigned long long) *ppos);
> >>>> +
> >>>> + if (IS_SWAPFILE(inode)) {
> >>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
> >>>> + "file!\n");
> >>>> + return -EBUSY;
> >>>> + }
I don't know that we really need this. We should sweep through the NFS
code and kill all those IS_SWAPFILE() thingys. Or at least #define
IS_SWAPFILE(a) (0)
...
> >>>> +
> >>>> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
> >>>> +}
> >>>> +
> >>>> static int do_getlk(struct file *filp, int cmd, struct file_lock *fl)
> >>>> {
> >>>> struct inode *inode = filp->f_mapping->host;
> >>>>
Otherwise it looks fine...
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Suresh Jayaraman @ 2009-04-20 5:39 UTC (permalink / raw)
To: Masahiro Tamori
Cc: Mathieu Desnoyers, linux-nfs, ltt-dev, Trond.Myklebust, LKML,
linux-embedded
In-Reply-To: <91e0b5050904020542l6b38d7a6hab6d7ef8b4593425@mail.gmail.com>
Hi Trond,
Do you think this patch is OK? Can this be considered for merging?
Thanks,
Masahiro Tamori wrote:
> Hello Suresh and Mathieu,
>
> 2009/4/2 Suresh Jayaraman <sjayaraman@suse.de>:
>> Mathieu Desnoyers wrote:
>>> * Suresh Jayaraman (sjayaraman@suse.de) wrote:
>>>> This patch attempts to add splice writes support. In essence, it just
>>>> calls generic_file_splice_write() after doing a little sanity check.
>>>> This would allow LTTng users that are using NFS to store trace data.
>>>> There could be more applications that could be benefitted too.
>>>>
>>>> I have tested this using the Jens' test program and have found no
>>>> real issues. The test program is inlined below:
>>>>
>>> There is just a small checkpatch nit that I'll fix directly in place in
>>> the LTTng tree.
>>>
>>> WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
>>> #93: FILE: fs/nfs/file.c:564:
>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
>>>
>>> total: 0 errors, 1 warnings, 42 lines checked
>>>
>> Yes, I noticed it. There are quite a few places in nfs code where we
>> happened to use that (that doesn't imply that it shouldn't be fixed), so
>> I thought it's OK.
>>
>>> That's great ! I'll pull it in the LTTng tree so my users can try it.
>>> They currently cannot write LTTng traces to NFS mounts anyway.
>> Yes, please report the test results. Would appreciate it very much.
>>
>>
>> Thanks,
>
> Thank you for creating a patch !!
>
> I tested it, and it works fine.
>
> My environment is following,
> LTTV 0.12.10
> LTTng 0.100
> LTT Control 0.65
> Kernles 2.6.29
>
> LTTng version is old now, but the test is passed on ARM11 target.
>
> Furthermore, I run the splice test and the test is passed too.
> The test code is copied from
> http://kzk9.net/blog/2007/05/splice2.html
> (Japanese page)
>
> Thanks all people who commented this issue.
>
> Best regards,
> Masahiro Tamori
>
>>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
>>>> index 90f292b..13d6a00 100644
>>>> --- a/fs/nfs/file.c
>>>> +++ b/fs/nfs/file.c
>>>> @@ -47,6 +47,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
>>>> size_t count, unsigned int flags);
>>>> static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
>>>> unsigned long nr_segs, loff_t pos);
>>>> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
>>>> + struct file *filp, loff_t *ppos,
>>>> + size_t count, unsigned int flags);
>>>> static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
>>>> unsigned long nr_segs, loff_t pos);
>>>> static int nfs_file_flush(struct file *, fl_owner_t id);
>>>> @@ -76,6 +79,7 @@ const struct file_operations nfs_file_operations = {
>>>> .lock = nfs_lock,
>>>> .flock = nfs_flock,
>>>> .splice_read = nfs_file_splice_read,
>>>> + .splice_write = nfs_file_splice_write,
>>>> .check_flags = nfs_check_flags,
>>>> .setlease = nfs_setlease,
>>>> };
>>>> @@ -550,6 +554,26 @@ out_swapfile:
>>>> goto out;
>>>> }
>>>>
>>>> +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;
>>>> + struct inode *inode = dentry->d_inode;
>>>> +
>>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
>>>> + dentry->d_parent->d_name.name, dentry->d_name.name,
>>>> + (unsigned long) count, (unsigned long long) *ppos);
>>>> +
>>>> + if (IS_SWAPFILE(inode)) {
>>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
>>>> + "file!\n");
>>>> + return -EBUSY;
>>>> + }
>>>> +
>>>> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
>>>> +}
>>>> +
>>>> static int do_getlk(struct file *filp, int cmd, struct file_lock *fl)
>>>> {
>>>> struct inode *inode = filp->f_mapping->host;
>>>>
>>
>> --
>> Suresh Jayaraman
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev@lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Suresh Jayaraman
^ permalink raw reply
* Re: [PATCH] Wait for console to become available, v2
From: David VomLehn @ 2009-04-19 23:17 UTC (permalink / raw)
To: Andi Kleen
Cc: Linux Kernel Mailing List, Andrew Morton,
Linux Embedded Mailing List, Linux USB Mailing List
In-Reply-To: <20090419163923.GS14687-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org>
Andi Kleen wrote:
> On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
>> Andi Kleen wrote:
>>> VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> writes:
...
>>> Also a setting to panic in this case might be useful, normally a system
>>> without console is not very useful and needs to be rebooted anyways.
>> Umm, those of us in the embedded space have the, perhaps misguided,
>> notion that our systems are quite useful without consoles...
>
> That seems more like a special case that shouldn't be default?
I have to disagree. Panicing because you can't open /dev/console is
likely to mean that you get no output at all and so no chance to see a
message explaining why the open failed. If the open failure is all that
happened, the rest of the system may very well come up normally. You
would then be able to look at the kernel log and diagnose the issue.
In any case, the purpose of this patch is fix USB consoles to work as
they did before parallelized startup. This involves addressing a race
condition that, theoretically, always existed but which previously
hadn't been a problem. Changing the behavior when init_post() can't open
/dev/console seems out of scope.
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Wait for console to become available, v2
From: Andi Kleen @ 2009-04-19 16:39 UTC (permalink / raw)
To: David VomLehn
Cc: Andi Kleen, Linux Kernel Mailing List, Andrew Morton,
Linux Embedded Mailing List, Linux USB Mailing List
In-Reply-To: <49EB5008.1090000-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
> Andi Kleen wrote:
> >VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> writes:
> >>History
> >>v2 Wait for the preferred console rather than any console. Make the
> >> delay interval a tunable.
> >
> >CONFIG tunables are usually a bad idea. What should a binary distribution
> >kernel set? Better make it a boot option with a reasonable default.
>
> Your point about boot options is well taken; I released a more recent
> version of this patch with boot options last Friday and would appreciate
> your comments.
Ah missed that sorry.
>
> >Also a setting to panic in this case might be useful, normally a system
> >without console is not very useful and needs to be rebooted anyways.
>
> Umm, those of us in the embedded space have the, perhaps misguided,
> notion that our systems are quite useful without consoles...
That seems more like a special case that shouldn't be default?
-Andi
--
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Wait for console to become available, v2
From: David VomLehn @ 2009-04-19 16:23 UTC (permalink / raw)
To: Andi Kleen
Cc: Linux Kernel Mailing List, Andrew Morton,
Linux Embedded Mailing List, Linux USB Mailing List
In-Reply-To: <874owlqcce.fsf-3rXA9MLqAseW/qJFnhkgxti2O/JbrIOy@public.gmane.org>
Andi Kleen wrote:
> VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> writes:
>> History
>> v2 Wait for the preferred console rather than any console. Make the
>> delay interval a tunable.
>
> CONFIG tunables are usually a bad idea. What should a binary distribution
> kernel set? Better make it a boot option with a reasonable default.
Your point about boot options is well taken; I released a more recent
version of this patch with boot options last Friday and would appreciate
your comments.
> Also a setting to panic in this case might be useful, normally a system
> without console is not very useful and needs to be rebooted anyways.
Umm, those of us in the embedded space have the, perhaps misguided,
notion that our systems are quite useful without consoles...
But, more to the specific point, the console code is pretty smart. If
you set your delay interval too short and the console comes up later,
you won't see output to /dev/console, but you *will* see kernel printk
output, including the message that no console could be opened. This
would, hopefully, point the user to the problem. I can also make the
message more specific about which parameter to set in that case.
>
> -Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Wait for console to become available, v2
From: Andi Kleen @ 2009-04-19 8:25 UTC (permalink / raw)
To: VomLehn
Cc: Linux Kernel Mailing List, Andrew Morton,
Linux Embedded Mailing List, Linux USB Mailing List
In-Reply-To: <20090416190837.GA26734@cuplxvomd02.corp.sa.net>
VomLehn <dvomlehn@cisco.com> writes:
>
> History
> v2 Wait for the preferred console rather than any console. Make the
> delay interval a tunable.
CONFIG tunables are usually a bad idea. What should a binary distribution
kernel set? Better make it a boot option with a reasonable default.
Also a setting to panic in this case might be useful, normally a system
without console is not very useful and needs to be rebooted anyways.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH] Wait for console to become available, ver 3.1
From: David VomLehn @ 2009-04-17 23:22 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux Embedded Mailing List, Linux USB Mailing List,
Andrew Morton
Parallelization to improve boot times has been successful enough that race
conditions now exist between the init_post() open of /dev/console and
initialization of the console device. When this occurs, opening /dev/console
fails and any applications inherited from init have no standard in/out/error
devices. This is expected behavior if no console device is available, but
quite unfortunate in the case where the console is just a bit slow waking up.
Some buses, such as USB, offer no guarantees about how long it takes to
discover devices, so there is no reliable way to distinguish between a missing
console and a slow one. The pragmatic approach taken in this patch is to
wait for a while to see if a console shows up, and just go on if it doesn't.
The default delay is 1000 msec (1 second).
There are two new command line parameters:
consolewait Wait forever for a console to be registered
consoledelay=msec Use the given number of milliseconds as the delay
interval instead of the default
Note that, though these parameters are modeled after the rootwait and rootdelay
parameters, details differ. Instead of sleeping and polling, which can increase
boot time, this code uses a waitqueue and will proceed as soon as a console is
available.
It could be argued that providing both command line parameters and a Kconfig
option for the console wait time is over-engineering. There doesn't really
seem to be a reasonable way to determine a default, though, which drives the
Kconfig option. The selection of USB devices connected to the system can
only be known at runtime, which drives the need for command line parameters.
History
v3.1 Correct the abbreviation for milliseconds in
Documentation/kernel-parameters.txt to be "ms", not "mS". Thanks to
Peter Anvin for this.
v3 Increase the default delay to 1 second and add kernel command line
parameters to override the default delay. Thanks to David Brownell for
his helpful suggestions.
v2 Wait for the preferred console rather than any console. Make the
delay interval a tunable.
v1 Initial version
Signed-off-by: David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
Documentation/kernel-parameters.txt | 10 ++++++++
arch/mips/configs/powertv_defconfig | 2 +-
init/Kconfig | 12 ++++++++++
kernel/printk.c | 41 +++++++++++++++++++++++++++++++++++
4 files changed, 64 insertions(+), 1 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6172e43..641e7a0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -507,6 +507,16 @@ and is between 256 and 4096 characters. It is defined in the file
console=brl,ttyS0
For now, only VisioBraille is supported.
+ consoledelay=ms [KNL] Wait up to ms milliseconds for the preferred
+ console to be registered, then continue. Useful for
+ systems where a console may not be plugged in, such as
+ for USB serial devices.
+
+ consolewait [KNL] Wait (indefinitely) for preferred console device
+ to be registered. Useful, for example, for USB serial
+ devices, but will never complete booting if no console
+ is plugged in.
+
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
diff --git a/arch/mips/configs/powertv_defconfig b/arch/mips/configs/powertv_defconfig
index 7311e63..b4a046d 100644
--- a/arch/mips/configs/powertv_defconfig
+++ b/arch/mips/configs/powertv_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc2
-# Thu Apr 16 11:29:44 2009
+# Fri Apr 17 12:38:42 2009
#
CONFIG_MIPS=y
diff --git a/init/Kconfig b/init/Kconfig
index 7be4d38..a04eba1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -835,6 +835,18 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CONSOLE_WAIT
+ int "Default number of milliseconds to wait for console device"
+ default 1000
+ help
+ Some systems use console devices, such as USB serial devices, which
+ may not be present or which may take an unspecified amount of time
+ to be initialized. This setting is the default for the maximum number
+ of milliseconds the system will wait for a console to be registered.
+ This value can be overridden by the command line parameters
+ consolewait, to wait forever, or consoledelay=msec, to give a
+ different value for the wait.
+
config BUG
bool "BUG() support" if EMBEDDED
default y
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..aa6db96 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -105,6 +105,11 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Definitions controlling the wait for a console device to be initialized */
+static bool console_wait; /* If true, wait forever for console */
+static long console_delay = CONFIG_PRINTK_CONSOLE_WAIT; /* In milliseconds */
+static DECLARE_WAIT_QUEUE_HEAD(console_wq);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -195,6 +200,30 @@ out:
__setup("log_buf_len=", log_buf_len_setup);
+/*
+ * Set up to wait forever for the console to appear
+ * @str: Ignored
+ * Returns one.
+ */
+static int __init consolewait_setup(char *str)
+{
+ console_wait = true;
+ return 1;
+}
+__setup("consolewait", consolewait_setup);
+
+/*
+ * Set the delay, in milliseconds, to wait for the console.
+ * @str: Pointer to the start of the delay value
+ * Returns one.
+ */
+static int __init consoledelay_setup(char *str)
+{
+ console_delay = simple_strtoul(str, NULL, 10);
+ return 1;
+}
+__setup("consoledelay=", consoledelay_setup);
+
#ifdef CONFIG_BOOT_PRINTK_DELAY
static unsigned int boot_delay; /* msecs delay after each printk during bootup */
@@ -1081,6 +1110,17 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* The console device may not be initialized yet. We can either wait
+ * forever if consolewait is specified on the command line, or wait
+ * for some number of milliseconds if console_delay=msec is used */
+ if (console_wait)
+ wait_event(console_wq, preferred_console >= 0);
+
+ else if (wait_event_timeout(console_wq, preferred_console >= 0,
+ msecs_to_jiffies(console_delay)) == 0)
+ pr_warning("No preferred console after waiting %ld msec; "
+ "continuing anyway\n", console_delay);
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1230,6 +1270,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wq);
}
EXPORT_SYMBOL(register_console);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [Patch] Wait for console to become available, ver 3
From: H. Peter Anvin @ 2009-04-17 22:15 UTC (permalink / raw)
To: David VomLehn
Cc: Linux Kernel Mailing List, Linux Embedded Mailing List,
Linux USB Mailing List, Andrew Morton
In-Reply-To: <20090417213148.GA27825@cuplxvomd02.corp.sa.net>
David VomLehn wrote:
>>
> + consoledelay=mS [KNL] Wait up to mS milliseconds for the a preferred
> + console to be registered, then continue. Useful for
> + systems where a console may not be plugged in, such as
> + for USB serial devices.
> +
Pet peeve:
The symbol for millisecond is "ms". mS is a unit of conductance,
millisiemens.
-hpa
^ permalink raw reply
* [Patch] Wait for console to become available, ver 3
From: David VomLehn @ 2009-04-17 21:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux Embedded Mailing List, Linux USB Mailing List,
Andrew Morton
Parallelization to improve boot times has been successful enough that race
conditions now exist between the init_post() open of /dev/console and
initialization of the console device. When this occurs, opening /dev/console
fails and any applications inherited from init have no standard in/out/error
devices. This is expected behavior if no console device is available, but
quite unfortunate in the case where the console is just a bit slow waking up.
Some buses, such as USB, offer no guarantees about how long it takes to
discover devices, so there is no reliable way to distinguish between a missing
console and a slow one. The pragmatic approach taken in this patch is to
wait for a while to see if a console shows up, and just go on if it doesn't.
The default delay is 1000 msec (1 second).
There are two new command line parameters:
consolewait Wait forever for a console to be registered
consoledelay=msec Use the given number of milliseconds as the delay
interval instead of the default
Note that, though these parameters are modeled after the rootwait and rootdelay
parameters, details differ. Instead of sleeping and polling, which can increase
boot time, this code uses a waitqueue and will proceed as soon as a console is
available.
It could be argued that providing both command line parameters and a Kconfig
option for the console wait time is over-engineering. There doesn't really
seem to be a reasonable way to determine a default, though, which drives the
Kconfig option. The selection of USB devices connected to the system can
only be known at runtime, which drives the need for command line parameters.
History
v3 Increase the default delay to 1 second and add kernel command line
parameters to override the default delay. Thanks to David Brownell for
his helpful suggestions.
v2 Wait for the preferred console rather than any console. Make the
delay interval a tunable.
v1 Initial version
Signed-off-by: David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
Documentation/kernel-parameters.txt | 10 ++++++++
arch/mips/configs/powertv_defconfig | 2 +-
init/Kconfig | 12 ++++++++++
kernel/printk.c | 41 +++++++++++++++++++++++++++++++++++
4 files changed, 64 insertions(+), 1 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6172e43..2b0c4e6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -507,6 +507,16 @@ and is between 256 and 4096 characters. It is defined in the file
console=brl,ttyS0
For now, only VisioBraille is supported.
+ consoledelay=mS [KNL] Wait up to mS milliseconds for the a preferred
+ console to be registered, then continue. Useful for
+ systems where a console may not be plugged in, such as
+ for USB serial devices.
+
+ consolewait [KNL] Wait (indefinitely) for preferred console device
+ to be registered. Useful, for example, for USB serial
+ devices, but will never complete booting if no console
+ is plugged in.
+
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
diff --git a/arch/mips/configs/powertv_defconfig b/arch/mips/configs/powertv_defconfig
index 7311e63..b4a046d 100644
--- a/arch/mips/configs/powertv_defconfig
+++ b/arch/mips/configs/powertv_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc2
-# Thu Apr 16 11:29:44 2009
+# Fri Apr 17 12:38:42 2009
#
CONFIG_MIPS=y
diff --git a/init/Kconfig b/init/Kconfig
index 7be4d38..a04eba1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -835,6 +835,18 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CONSOLE_WAIT
+ int "Default number of milliseconds to wait for console device"
+ default 1000
+ help
+ Some systems use console devices, such as USB serial devices, which
+ may not be present or which may take an unspecified amount of time
+ to be initialized. This setting is the default for the maximum number
+ of milliseconds the system will wait for a console to be registered.
+ This value can be overridden by the command line parameters
+ consolewait, to wait forever, or consoledelay=msec, to give a
+ different value for the wait.
+
config BUG
bool "BUG() support" if EMBEDDED
default y
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..aa6db96 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -105,6 +105,11 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Definitions controlling the wait for a console device to be initialized */
+static bool console_wait; /* If true, wait forever for console */
+static long console_delay = CONFIG_PRINTK_CONSOLE_WAIT; /* In milliseconds */
+static DECLARE_WAIT_QUEUE_HEAD(console_wq);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -195,6 +200,30 @@ out:
__setup("log_buf_len=", log_buf_len_setup);
+/*
+ * Set up to wait forever for the console to appear
+ * @str: Ignored
+ * Returns one.
+ */
+static int __init consolewait_setup(char *str)
+{
+ console_wait = true;
+ return 1;
+}
+__setup("consolewait", consolewait_setup);
+
+/*
+ * Set the delay, in milliseconds, to wait for the console.
+ * @str: Pointer to the start of the delay value
+ * Returns one.
+ */
+static int __init consoledelay_setup(char *str)
+{
+ console_delay = simple_strtoul(str, NULL, 10);
+ return 1;
+}
+__setup("consoledelay=", consoledelay_setup);
+
#ifdef CONFIG_BOOT_PRINTK_DELAY
static unsigned int boot_delay; /* msecs delay after each printk during bootup */
@@ -1081,6 +1110,17 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* The console device may not be initialized yet. We can either wait
+ * forever if consolewait is specified on the command line, or wait
+ * for some number of milliseconds if console_delay=msec is used */
+ if (console_wait)
+ wait_event(console_wq, preferred_console >= 0);
+
+ else if (wait_event_timeout(console_wq, preferred_console >= 0,
+ msecs_to_jiffies(console_delay)) == 0)
+ pr_warning("No preferred console after waiting %ld msec; "
+ "continuing anyway\n", console_delay);
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1230,6 +1270,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wq);
}
EXPORT_SYMBOL(register_console);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] Wait for console to become available, v2
From: VomLehn @ 2009-04-16 19:08 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linux Embedded Mailing List,
Linux USB Mailing List
Parallelization to improve boot times has been successful enough that race
conditions now exist between the init_post() open of /dev/console and
initialization of the console device. When this occurs, opening /dev/console
fails and any applications inherited for init have no standard in/out/err
devices. This is expected behavior if no console device is available, but
quite unfortunate in the case where the console is just a bit slow waking up.
Some buses, such as USB, offer no guarantees about how long it takes to
discover devices, so there is no reliable way to distinguish between a missing
console and a slow one. The pragmatic approach taken in this patch is to
wait for a while to see if a console shows up, and just go on if it doesn't.
The default delay interval is set to 500 msec (0.5 seconds) based on a sample
size of one device (cp2101) but is a tunable. If the console shows up sooner,
we will continue immediately.
History
v2 Wait for the preferred console rather than any console. Make the
delay interval a tunable.
v1 Initial version
Signed-off-by: David VomLehn <dvomlehn@cisco.com>
---
init/Kconfig | 10 ++++++++++
kernel/printk.c | 11 +++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 7be4d38..5d5b0fa 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -835,6 +835,16 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CONSOLE_WAIT
+ int "Number of milliseconds to wait for console device"
+ default 500
+ help
+ Some systems use console devices, such as USB serial devices, which
+ may not be present or which may take an unspecified amount of time
+ to be initialized. This setting determines the maximum number of
+ milliseconds the system will wait for a console to be registered.
+ Slow devices may require this value be increased.
+
config BUG
bool "BUG() support" if EMBEDDED
default y
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..3a05c8a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -105,6 +105,9 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Wait queue controlling the wait for a console device */
+static DECLARE_WAIT_QUEUE_HEAD(console_wait);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -1081,6 +1084,13 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* Wait a while for a console to show up. If one doesn't show up
+ * for too long, we'll just continue without a console. */
+ if (wait_event_timeout(console_wait, preferred_console >= 0,
+ CONFIG_PRINTK_CONSOLE_WAIT) == 0)
+ pr_warning("No preferred console after waiting %u msec; "
+ "continuing anyway\n", CONFIG_PRINTK_CONSOLE_WAIT);
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1230,6 +1240,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wait);
}
EXPORT_SYMBOL(register_console);
^ permalink raw reply related
* Re: root on Squashfs breaks mknod
From: Markus Brunner @ 2009-04-16 17:21 UTC (permalink / raw)
To: squashfs-devel; +Cc: linux-embedded
In-Reply-To: <200904021340.27277.super.firetwister@gmail.com>
Hi,
I've got good news:
1. It has nothing to do with squashfs, more with the readonly loopback device
2. The Problem is with an old version of uclibc
3. It's already fixed in the latest version of uclibc.
4. Everybody who cannot update uclibc, can use mknod of klibc
Best Regards
Markus
^ permalink raw reply
* [PATCH] Wait for console to become available
From: VomLehn @ 2009-04-14 23:28 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Linux Embedded Mailing List
Work to improve boot times appears to be successful enough that a race
condition has been created between the open of /dev/console in init_post
and USB serial device initialization. Embedded systems are probably the
primary users of USB serial devices, though I can certainly image blade
servers using them, as well.
This patch works for me and, though it's possible this is all that needs
to be done, I think it's likely there are some other changes required,
as well.
Signed-off-by: David VomLehn <dvomlehn@cisco>
---
kernel/printk.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index e3602d0..39f554a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -104,6 +104,10 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Definitions for waiting until a console is registered */
+#define MAX_CONSOLE_WAIT msecs_to_jiffies(2000)
+static DECLARE_WAIT_QUEUE_HEAD(console_wait);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -1062,6 +1066,10 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* Wait a while for a console to show up. If one doesn't show up
+ * for too long, we'll just continue without a console. */
+ wait_event_timeout(console_wait, console_drivers, MAX_CONSOLE_WAIT);
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1211,6 +1219,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wait);
}
EXPORT_SYMBOL(register_console);
^ permalink raw reply related
* video (VGA) object-files unconditionally built/included?
From: Dag Bakke @ 2009-04-10 16:55 UTC (permalink / raw)
To: linux-embedded
Hi.
I am putting together a tiny kernel for an embedded x86 target. Space is
tight, so I try to shave every kB I can get rid of.
I don't have anything resembling VGA or graphics, and my .config
reflects that. (Serial console.)
Yet, when building the kernel I see:
LZMA arch/x86/boot/compressed/vmlinux.bin.lzma
CC arch/x86/boot/video.o
CC arch/x86/boot/video-mode.o
CC arch/x86/boot/version.o
CC arch/x86/boot/video-vga.o
CC arch/x86/boot/video-vesa.o
CC arch/x86/boot/video-bios.o
# strings arch/x86/boot/bzImage | egrep -i 'vesa|vga|bios|mode'
+VESA
0123456789ABCDEFPress <ENTER> to see video modes available, <SPACE> to
continue, or wait 30 sec
Mode: Resolution: Type:
Enter a video mode or "scan" to scan for additional modes:
Undefined video mode number: %x
VESA
BIOS
The video* objects sums up to 87kB. Can I get rid of that somehow? I am
using current git.
This is my .config:
http://tapas.homeip.net/~dagb/tiny.config
Cc: is appreciated.
Thanks,
Dag B
^ permalink raw reply
* Versatile PB Board Support for ARMv6 and ARMv7
From: Mark Miller @ 2009-04-08 3:37 UTC (permalink / raw)
To: linux-kernel; +Cc: Embedded Linux mailing list, qemu-devel
(Apologies if this appeared twice for some. My mail client was
misbehaving and sending HTML messages)
In late October 2008, according to the git logs, the methodology for
selecting a processor on several boards, at least the Versatile PB
board was changed so that it automatically selects CPU_ARM926T as a
hidden symbol.
The reason I have a question, is since QEMU currently can emulate a
Versatile PB board with other processors than just the ARM926T (Such
as the ARM1136 (ARMv6) and Cortex-A8 (ARMv7), is there a good way to
allow that in the mainstream kernel? Previously the patch was to just
add extra potential dependencies on CPU_V6 and CPU_V7, so that by
selecting MACH_VERSATILE_PB, you could select ARMv6/v7 support.
Currently I'm just deleting the select statement, and having all the
CPUs appear, as no longer hidden symbols. My question is, what is the
best way to allow for other processors for this board in Kconfig, so
it could be submitted to the mainstream kernel?
--
Mark A. Miller
mark@mirell.org
^ permalink raw reply
* Versatile PB Board Support for ARMv6 and ARMv7
From: Mark A. Miller @ 2009-04-08 3:35 UTC (permalink / raw)
To: linux-kernel; +Cc: qemu-devel, Embedded Linux mailing list
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
In late October 2008, according to the git logs, the methodology for
selecting a processor on several boards, at least the Versatile PB board was
changed so that it automatically selects CPU_ARM926T as a hidden symbol.
The reason I have a question, is since QEMU currently can emulate a
Versatile PB board with other processors than just the ARM926T (Such as the
ARM1136 (ARMv6) and Cortex-A8 (ARMv7), is there a good way to allow that in
the mainstream kernel? Previously the patch was to just add extra potential
dependencies on CPU_V6 and CPU_V7, so that by selecting MACH_VERSATILE_PB,
you could select ARMv6/v7 support.
Currently I'm just deleting the select statement, and having all the CPUs
appear, as no longer hidden symbols. My question is, what is the best way to
allow for other processors for this board in Kconfig, so it could be
submitted to the mainstream kernel?
--
Mark A. Miller
mark@mirell.org
"My greatest strength, I guess it would be my humility. My greatest
weakness, it's possible that I'm a little too awesome" - Barack Obama
[-- Attachment #2: Type: text/html, Size: 1226 bytes --]
^ permalink raw reply
* e2factory: Embedded Linux build system released under the GPL
From: Matthias Kaehlcke @ 2009-04-06 9:05 UTC (permalink / raw)
To: linux-embedded
thought this might be interesting for people on this list:
e2factory, a build management system for embedded system developers,
has been released as open source by emlix. Emlix, a specialist in
creating embedded linux systems, developed e2factory to manage the
complexity of bringing together numerous open source and free software
packages to create releases for its customers. The e2factory software
can use multiple source code control systems, such as git or
subversion, within the same project if necessary, and the
configuration and results of building with e2factory are themselves
version controlled. This allows the build process to be easily
reproducible and that in turn assists in the validation and auditing
of the delivered software.
The build system also documents the open source licenses of any
modules used, making it easier to comply with those
licenses. e2factory has been released under the GPL3 and emlix is
offering a professional edition with a service contract.
http://www.h-online.com/open/e2factory-opens-its-gates--/news/112759
more info about e2factory:
http://www.emlix.com/fileadmin/emlix/dokumente/090303_PI_e2factorygoesOS_en1.doc
http://www.emlix.com/sol-e2factory.html?&language=en
http://www.e2factory.org
--
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona
Don't walk behind me, I may not lead
Don't walk in front of me, I may not follow
Just walk beside me and be my friend
(Albert Camus)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Squashfs 4.0 tools (for 2.6.29) released
From: Phillip Lougher @ 2009-04-05 23:41 UTC (permalink / raw)
To: squashfs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Linux Kernel Development, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
Linux Embedded Maillist
Hi,
I'm pleased to announce the first release of the squashfs 4.0 tools.
These are needed by any Squashfs users using linux 2.6.29. They are available
from http://sourceforge.net/projects/squashfs
The changes from the change-log are:
1. Unsquashfs improvements:
1.1 Support for 4.0 filesystems added.
1.2 Swapping macros rewritten.
1.3 Unsquashfs code restructured and split into separate files.
2. Mksquashfs improvements:
2.1 Swapping macros rewritten. Fixed little-endian layout allows
code to be optimised and only added at compile time for
big endian systems.
2.2 Support for pseudo files added.
New Mksquashfs options
Mksquashfs now supports pseudo files, these allow fake directories, character
and block devices to be specified and added to the Squashfs filesystem being
built, rather than requiring them to be present in the source directories.
This, for example, allows device nodes to be added to the filesystem without
requiring root access.
Phillip
------------------------------------------------------------------------------
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Masahiro Tamori @ 2009-04-02 12:42 UTC (permalink / raw)
To: Suresh Jayaraman, Mathieu Desnoyers
Cc: linux-nfs, ltt-dev, Trond.Myklebust, LKML, linux-embedded
In-Reply-To: <49D45E42.3050502@suse.de>
Hello Suresh and Mathieu,
2009/4/2 Suresh Jayaraman <sjayaraman@suse.de>:
> Mathieu Desnoyers wrote:
>> * Suresh Jayaraman (sjayaraman@suse.de) wrote:
>>> This patch attempts to add splice writes support. In essence, it just
>>> calls generic_file_splice_write() after doing a little sanity check.
>>> This would allow LTTng users that are using NFS to store trace data.
>>> There could be more applications that could be benefitted too.
>>>
>>> I have tested this using the Jens' test program and have found no
>>> real issues. The test program is inlined below:
>>>
>>
>> There is just a small checkpatch nit that I'll fix directly in place in
>> the LTTng tree.
>>
>> WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
>> #93: FILE: fs/nfs/file.c:564:
>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
>>
>> total: 0 errors, 1 warnings, 42 lines checked
>>
>
> Yes, I noticed it. There are quite a few places in nfs code where we
> happened to use that (that doesn't imply that it shouldn't be fixed), so
> I thought it's OK.
>
>> That's great ! I'll pull it in the LTTng tree so my users can try it.
>> They currently cannot write LTTng traces to NFS mounts anyway.
>
> Yes, please report the test results. Would appreciate it very much.
>
>
> Thanks,
Thank you for creating a patch !!
I tested it, and it works fine.
My environment is following,
LTTV 0.12.10
LTTng 0.100
LTT Control 0.65
Kernles 2.6.29
LTTng version is old now, but the test is passed on ARM11 target.
Furthermore, I run the splice test and the test is passed too.
The test code is copied from
http://kzk9.net/blog/2007/05/splice2.html
(Japanese page)
Thanks all people who commented this issue.
Best regards,
Masahiro Tamori
>
>>>
>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
>>> index 90f292b..13d6a00 100644
>>> --- a/fs/nfs/file.c
>>> +++ b/fs/nfs/file.c
>>> @@ -47,6 +47,9 @@ static ssize_t nfs_file_splice_read(struct file *filp, loff_t *ppos,
>>> size_t count, unsigned int flags);
>>> static ssize_t nfs_file_read(struct kiocb *, const struct iovec *iov,
>>> unsigned long nr_segs, loff_t pos);
>>> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
>>> + struct file *filp, loff_t *ppos,
>>> + size_t count, unsigned int flags);
>>> static ssize_t nfs_file_write(struct kiocb *, const struct iovec *iov,
>>> unsigned long nr_segs, loff_t pos);
>>> static int nfs_file_flush(struct file *, fl_owner_t id);
>>> @@ -76,6 +79,7 @@ const struct file_operations nfs_file_operations = {
>>> .lock = nfs_lock,
>>> .flock = nfs_flock,
>>> .splice_read = nfs_file_splice_read,
>>> + .splice_write = nfs_file_splice_write,
>>> .check_flags = nfs_check_flags,
>>> .setlease = nfs_setlease,
>>> };
>>> @@ -550,6 +554,26 @@ out_swapfile:
>>> goto out;
>>> }
>>>
>>> +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;
>>> + struct inode *inode = dentry->d_inode;
>>> +
>>> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
>>> + dentry->d_parent->d_name.name, dentry->d_name.name,
>>> + (unsigned long) count, (unsigned long long) *ppos);
>>> +
>>> + if (IS_SWAPFILE(inode)) {
>>> + printk(KERN_INFO "NFS: attempt to write to active swap"
>>> + "file!\n");
>>> + return -EBUSY;
>>> + }
>>> +
>>> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
>>> +}
>>> +
>>> static int do_getlk(struct file *filp, int cmd, struct file_lock *fl)
>>> {
>>> struct inode *inode = filp->f_mapping->host;
>>>
>>
>
>
> --
> Suresh Jayaraman
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox