* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Johnny Hung @ 2009-11-19 10:19 UTC (permalink / raw)
To: Viral Mehta; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <4B05187F.6030809@einfochips.com>
It doesn't works. :(
2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
> How about putting \n at the end ?
>
> Just try out,
>
> __asm__ volatile ("movl %0, %%ebx\n"
> "movl %1, %%ecx\n"
>
>
>
>
> Thanks,
> Viral Mehta,
> Embedded Software Engineer,
> Tel. No. 91 79 26563705, Ext. 423
> www.einfochips.com <http://www.einfochips.com>
> Prepare and Prevent rather than Repair and Repent
>
>
> Johnny Hung wrote:
>>
>> Hi All:
>> I want to move two local valuables to x86 arch CPU ebx, ecx
>> register and do outb cpu instruction by using AT&A inline asm in
>> kernel driver. The following code was I wrote but gcc report syntax
>> error:
>> ==
>> unsigned int val = 10;
>> unsigned int tmp = 5;
>> ....
>> __asm__ volatile ("movl %0, %%ebx"
>> "movl %1, %%ecx"
>> "outb $0x27, $0xb2"
>> :
>> :"r"(val), "r"(tmp)
>> :"%ebx", "%ecx"
>> );
>>
>> Does anyone can point me out. Any reply is appreciated.
>>
>> BRs, H. Johnny
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>>
>> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>>
>>
>>
>
> --
> _____________________________________________________________________
> Disclaimer: This e-mail message and all attachments transmitted with it
> are intended solely for the use of the addressee and may contain legally
> privileged and confidential information. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby
> notified that any dissemination, distribution, copying, or other use of
> this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any
> views expressed in this message are those of the individual sender
> unless otherwise stated.Company has taken enough precautions to prevent
> the spread of viruses. However the company accepts no liability for any
> damage caused by any virus transmitted by this email.
> _____________________________________________________________________
>
>
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Viral Mehta @ 2009-11-19 10:05 UTC (permalink / raw)
To: Johnny Hung; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <cb9ecdfa0911190150w4edbacdfp24a7069c618193f4@mail.gmail.com>
How about putting \n at the end ?
Just try out,
__asm__ volatile ("movl %0, %%ebx\n"
"movl %1, %%ecx\n"
Thanks,
Viral Mehta,
Embedded Software Engineer,
Tel. No. 91 79 26563705, Ext. 423
www.einfochips.com <http://www.einfochips.com>
Prepare and Prevent rather than Repair and Repent
Johnny Hung wrote:
> Hi All:
> I want to move two local valuables to x86 arch CPU ebx, ecx
> register and do outb cpu instruction by using AT&A inline asm in
> kernel driver. The following code was I wrote but gcc report syntax
> error:
> ==
> unsigned int val = 10;
> unsigned int tmp = 5;
> ....
> __asm__ volatile ("movl %0, %%ebx"
> "movl %1, %%ecx"
> "outb $0x27, $0xb2"
> :
> :"r"(val), "r"(tmp)
> :"%ebx", "%ecx"
> );
>
> Does anyone can point me out. Any reply is appreciated.
>
> BRs, H. Johnny
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
>
> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>
>
>
--
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
^ permalink raw reply
* How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Johnny Hung @ 2009-11-19 9:50 UTC (permalink / raw)
To: kernelnewbies, linux-kernel, linux-embedded
Hi All:
I want to move two local valuables to x86 arch CPU ebx, ecx
register and do outb cpu instruction by using AT&A inline asm in
kernel driver. The following code was I wrote but gcc report syntax
error:
==
unsigned int val = 10;
unsigned int tmp = 5;
....
__asm__ volatile ("movl %0, %%ebx"
"movl %1, %%ecx"
"outb $0x27, $0xb2"
:
:"r"(val), "r"(tmp)
:"%ebx", "%ecx"
);
Does anyone can point me out. Any reply is appreciated.
BRs, H. Johnny
^ permalink raw reply
* Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Aras Vaichas @ 2009-11-18 21:02 UTC (permalink / raw)
To: Bill Gatliff; +Cc: David Brownell, linux-embedded
In-Reply-To: <4B02C8AE.8050600@billgatliff.com>
2009/11/18 Bill Gatliff <bgat@billgatliff.com>
> The jitter can be quite low (100's of usecs) on a 200 MHz ARM9 chip, in
> fact, but you'll eat your battery alive if it's a portable device. And
> the jitter will also destroy your waveform at high or low duty cycles.
I agree with both of you, and I have physically tested bit-banged PWM
with an LED, a servo and a speaker. In all cases the jitter is
immediately obvious. The LED flickers noticeably (it is a very good
candle effect and system load indicator), the speaker crackles with
the white(ish) noise of the jitter, and the servo becomes unuseable.
It's pretty easy to do some math to prove it. Assume 100usec jitter.
Say you want to run a speaker at 1kHz. You need a 50% duty cycle PWM
running at a 1ms period. 100usec is a 10% error on 1ms. Therefore the
frequency will shift by 10% or 100Hz. Frequency resolution of the
human ear is 0.36 Hz within the octave of 1,000–2,000 Hz so you will
notice a 100Hz shift. What you end up hearing is 1kHz + noise. Look
at it musically, C6 is 1046Hz and D6 is 1174Hz. So a jump of about
130Hz is a full 2 semitones! Totally useless for playing any sort of
music or pleasant sounding warning tones.
Servo motors require a 1ms to 2ms pulse to hold a position between
about 0 and 180 degrees. A jitter of 100usec is physically equal to an
error of 100usec/1ms = 10% on the servo output arm which is equal to
10% x 180 degrees = 18degrees of positional error! It is alarming to
watch what happens as the CPU is loaded.
For non-commercial products these artifacts might be acceptable, but I
wouldn't use it for anything that a customer will comment on.
Aras
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Eric W. Biederman @ 2009-11-18 18:16 UTC (permalink / raw)
To: Tim Bird
Cc: Matt Mackall, David VomLehn, dedekind1@gmail.com, Marco Stornelli,
Simon Kagstrom, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org, dwm2@infradead.org,
linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com
In-Reply-To: <4B043467.8000708@am.sony.com>
Tim Bird <tim.bird@am.sony.com> writes:
> Eric W. Biederman wrote:
>> Matt Mackall <mpm@selenic.com> writes:
>>
>>> As much as I like kexec, it loses on memory footprint by about 100x.
>>> It's not appropriate for all use cases, especially things like
>>> consumer-grade wireless access points and phones.
>>
>> In general I agree. The cost of a second kernel and initrd can be
>> prohibitive in the smallest systems, and if you do a crash capture
>> with using a standalone app that is reinventing the wheel.
>>
>> That said. I can happily run kdump with only 16M-20M reserved.
>> So on many systems the cost is affordable.
>
> Understood. On some of my systems, the memory budget for the
> entire system is 10M. On most systems I work with, it is a
> struggle to reserve even 64K for this feature.
crash_kexec is really a glorified jump. It is possible to do a lot in
64K with a standalone application. If reliable capture of kernel
crashes is desirable to an embedded NAND device I expect a semi-general
purpose dedicated application for capturing at least dmesg from the
crashed kernel and write it to a file on a NAND filesystem could be
worth someones time.
On general purpose hardware we use a kernel and an initrd simply to
reduce the development work of supporting everything and the kitchen
sink. My impression is that embedded systems can afford a little more
setup time, and a custom compilation, and that the hardware you would like
to store things too is much more common.
Eric
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Tim Bird @ 2009-11-18 17:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Matt Mackall, David VomLehn, dedekind1@gmail.com, Marco Stornelli,
Simon Kagstrom, linux-embedded@vger.kernel.org,
akpm@linux-foundation.org, dwm2@infradead.org,
linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com
In-Reply-To: <m1vdh7byva.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Matt Mackall <mpm@selenic.com> writes:
>
>> As much as I like kexec, it loses on memory footprint by about 100x.
>> It's not appropriate for all use cases, especially things like
>> consumer-grade wireless access points and phones.
>
> In general I agree. The cost of a second kernel and initrd can be
> prohibitive in the smallest systems, and if you do a crash capture
> with using a standalone app that is reinventing the wheel.
>
> That said. I can happily run kdump with only 16M-20M reserved.
> So on many systems the cost is affordable.
Understood. On some of my systems, the memory budget for the
entire system is 10M. On most systems I work with, it is a
struggle to reserve even 64K for this feature.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Eric W. Biederman @ 2009-11-18 17:01 UTC (permalink / raw)
To: David VomLehn
Cc: dedekind1, Marco Stornelli, Simon Kagstrom, linux-embedded, akpm,
dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <20091118005337.GA19374@dvomlehn-lnx2.corp.sa.net>
David VomLehn <dvomlehn@cisco.com> writes:
>> > 2. Where would you suggest tying in? (Particularly since not all architectures
>> > currently support kdump)
>>
>> No changes are needed kernel side. You just need an appropriate kernel and
>> initrd for your purpose.
>
> I think I must still be missing something. I have dynamic data that I want
> to preserve as I reboot from a failed kernel to a fresh new kernel. By
> the time the fresh kernel starts init, the dynamic data (IP addresses, MAC
> addresses) has been re-written with new values. This is why I'm trying to
> preserve, but I may be running without disk or flash. This patch doesn't
> preserve the data, but it gets it into the kernel so that it can be
> preserved. At present, I'm preserving the data in a panic_notifier function,
> but I am not wedded to that. At present, the data will be copied to a
> section of memory retained across boots, but I know others will want to
> write to flash.
For memory retained across reboots, my inclination is to have a trivial
little tty/console driver that writes into that retained memory. You can
open the tty and write your user space data, and then at kernel panic time
the kernel will write it's data.
When people start writing to flash anything short of the most trivial
writes is non-trivial code that requires sleeps etc, etc. Not
something that is particularly reliable after a kernel failure. My
inclination in that case is to use crash_kexec and a small crash
kernel/initrd or if size is a real issue a standalone binary (ideally
Aboot like so different embedded platforms can share).
I'm sensitive about getting anything extra in the path before we call
crash_kexec as that is likely to lead to destabilization of that path.
Eric
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Eric W. Biederman @ 2009-11-18 16:07 UTC (permalink / raw)
To: Matt Mackall
Cc: David VomLehn, dedekind1, Marco Stornelli, Simon Kagstrom,
linux-embedded, akpm, dwm2, linux-kernel, paul.gortmaker
In-Reply-To: <1258505777.3081.4.camel@calx>
Matt Mackall <mpm@selenic.com> writes:
> As much as I like kexec, it loses on memory footprint by about 100x.
> It's not appropriate for all use cases, especially things like
> consumer-grade wireless access points and phones.
In general I agree. The cost of a second kernel and initrd can be
prohibitive in the smallest systems, and if you do a crash capture
with using a standalone app that is reinventing the wheel.
That said. I can happily run kdump with only 16M-20M reserved.
So on many systems the cost is affordable.
Eric
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Américo Wang @ 2009-11-18 9:01 UTC (permalink / raw)
To: David VomLehn
Cc: Eric W. Biederman, dedekind1, Marco Stornelli, Simon Kagstrom,
linux-embedded, akpm, dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <20091118005337.GA19374@dvomlehn-lnx2.corp.sa.net>
On Wed, Nov 18, 2009 at 8:53 AM, David VomLehn <dvomlehn@cisco.com> wrote:
> On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
>> David VomLehn <dvomlehn@cisco.com> writes:
>>
>> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
>> > ...
>> >> Why not use the kdump hook? If you handle a kernel panic that way
>> >> you get enhanced reliability and full user space support. All in a hook
>> >> that is already present and already works.
> ...
>> > 1. In what ways would this be better than, say, a panic_notifier?
>>
>> A couple of ways.
>>
>> - You are doing the work in a known good kernel instead of the kernel
>> that just paniced for some unknown reason.
>> - All of the control logic is in user space (not the kernel) so you can
>> potentially do something as simple as "date >> logfile" to get the
>> date.
>
> I think I see better what you're suggesting--passing the info to a kdump
> kernel and having it do whatever it wants. I don't think I want to do this,
> but I haven't used any of the kexec() stuff, so I may be missing the point.
> Some more context:
>
> My application is an embedded one, and one of the big things I need to do
> after a failure is to bring up a fully functional kernel ASAP. Once I have
> that kernel, I process all of the crash data in user space concurrently with
> running my main application. Because I'm embedded, I'm very limited in how
> much crash data I can save over a reboot, how much I can store, and how
> much I can send to a central collection point. This is good, since it doesn't
> take up a lot of resources, but core dumps are out of the question.
I think the problem of kdump is that it uses much memory to hold
the core, i.e. /proc/vmcore, and no way to free it unless using another
reboot. This is why Fedora only does some data-collection in the second
reboot after crash, and then reboots.
I got an idea many days ago, that is providing a way to "delete" /proc/vmcore
in the second reboot, so that we can have enough memory to continue without
another reboot. I am not sure if Eric likes this? Eric?
>
> As I understand kdump, I would also need to have a second kernel in memory
> to do the kdump work. It wouldn't need to be as big is the kernel that
> failed, but it would still require a significant amount of memory. On an
> embedded system, the idle memory may be a luxury we can't afford.
You can use only one kernel, as long as it is relocatable.
>
> I think this makes a kdump-based solution difficult, but if it can meet
> my requirements, I'd much rather use it (I've been following kdump since
> it's inception quite a few years ago, but it hasn't seemed a good match
> for embedded Linux). Does this still sound like a good match?
What do you think about my idea above? If we had that, would kdump
meet your requirements?
>
>> > 2. Where would you suggest tying in? (Particularly since not all architectures
>> > currently support kdump)
>>
>> No changes are needed kernel side. You just need an appropriate kernel and
>> initrd for your purpose.
>
> I think I must still be missing something. I have dynamic data that I want
> to preserve as I reboot from a failed kernel to a fresh new kernel. By
> the time the fresh kernel starts init, the dynamic data (IP addresses, MAC
> addresses) has been re-written with new values. This is why I'm trying to
> preserve, but I may be running without disk or flash. This patch doesn't
> preserve the data, but it gets it into the kernel so that it can be
> preserved. At present, I'm preserving the data in a panic_notifier function,
> but I am not wedded to that. At present, the data will be copied to a
> section of memory retained across boots, but I know others will want to
> write to flash.
>
I believe you can get everything from /proc/vmcore, if you use kexec,
after crash, with some tools like 'crash'.
>> All of the interesting architectures support kexec, and if an
>> architecture doesn't it isn't hard to add. The architecture specific
>> part is very simple. A pain to debug initially but very simple.
>
> I use MIPS processors, and it looks like it is supported. So long as it's
> stable, I'm happy to use it.
MIPS seems to have some kexec() support, but after looking at
arch/mips/kernel/machine_kexec.c, maybe the support is still
broken? But anyway, you are welcome to work on it. :)
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Artem Bityutskiy @ 2009-11-18 8:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Marco Stornelli, Simon Kagstrom, David VomLehn, linux-embedded,
akpm, dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <m1pr7hf93s.fsf@fess.ebiederm.org>
On Tue, 2009-11-17 at 07:45 -0800, Eric W. Biederman wrote:
> Artem Bityutskiy <dedekind1@gmail.com> writes:
>
> > On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
> >> 2009/11/17 Artem Bityutskiy <dedekind1@gmail.com>:
> >> > Take a look at my mails where I describe different complications we have
> >> > in our system. We really want to have an OOPS/panic + our environment
> >> > stuff to go together, at once. This makes things so much simpler.
> >> >
> >> > Really, what is the problem providing this trivial panic-note
> >> > capability, where user-space can give the kernel a small buffer, and ask
> >> > the kernel to print this buffer at the oops/panic time. Very simple and
> >> > elegant, and just solves the problem.
> >> >
> >> > Why perversions with time-stamps, separate storages are needed?
> >> >
> >> > IOW, you suggest a complicated approach, and demand explaining why we do
> >> > not go for it. Simply because it is unnecessarily complex.
> >>
> >> I don't think it's a complicated approach we are talking of a system
> >> log like syslog with a temporal information, nothing more.
> >
> > We need to store this information of NAND flash. Implementing logs on
> > NAND flash is about handling bad blocks, choosing format of records, and
> > may be even handling wear-levelling. This is not that simple.
> >
> > And then I have match oops to the userspace environment prints, using I
> > guess timestamps, which is also about complications in userspace.
> >
> >> > This patch solves the problem gracefully, and I'd rather demand you to point what
> >> > is the technical problem with the patches.
> >> >
> >>
> >> Simply because I think that we should avoid to include in the kernel
> >> things we can do in a simply way at user space level.
> >
> > If it is much easier to have in the kernel, then this argument does not
> > work, IMHO.
> >
> >> I think this
> >> patch is well done but it's one of the patches that are solutions "for
> >> embedded only", but it's only my opinion.
> >
> > Also IMHO, but having embedded-only things is not bad at all.
>
> Why not use the kdump hook? If you handle a kernel panic that way
> you get enhanced reliability and full user space support. All in a hook
> that is already present and already works.
For some reasons kdump does not work on ARM out of the box. We need to
investigate this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Matt Mackall @ 2009-11-18 0:56 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David VomLehn, dedekind1, Marco Stornelli, Simon Kagstrom,
linux-embedded, akpm, dwm2, linux-kernel, paul.gortmaker
In-Reply-To: <m1iqd8ptg9.fsf@fess.ebiederm.org>
On Tue, 2009-11-17 at 16:28 -0800, Eric W. Biederman wrote:
> David VomLehn <dvomlehn@cisco.com> writes:
>
> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> > ...
> >> Why not use the kdump hook? If you handle a kernel panic that way
> >> you get enhanced reliability and full user space support. All in a hook
> >> that is already present and already works.
> >
> > I'm a big fan of avoiding reinvention of the wheel--if I can use something
> > already present, I will. However, I'm not clear about how much of the problem
> > I'm addressing will be solved by using a kdump hook. If I understand
> > correctly, you'd still need a pseudo-file somewhere to actually get the data
> > from user space to kernel space. *Then* you could use a kdump hook to
> > transfer the data to flash or some memory area that will be retained across
> > boots. Is this the approach to which you were referring? If so, I have a
> > couple more questions:
> >
> > 1. In what ways would this be better than, say, a panic_notifier?
>
> A couple of ways.
>
> - You are doing the work in a known good kernel instead of the kernel
> that just paniced for some unknown reason.
> - All of the control logic is in user space (not the kernel) so you can
> potentially do something as simple as "date >> logfile" to get the
> date.
>
> > 2. Where would you suggest tying in? (Particularly since not all architectures
> > currently support kdump)
>
> No changes are needed kernel side. You just need an appropriate kernel and
> initrd for your purpose.
>
> All of the interesting architectures support kexec, and if an
> architecture doesn't it isn't hard to add. The architecture specific
> part is very simple. A pain to debug initially but very simple.
As much as I like kexec, it loses on memory footprint by about 100x.
It's not appropriate for all use cases, especially things like
consumer-grade wireless access points and phones.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: David VomLehn @ 2009-11-18 0:53 UTC (permalink / raw)
To: Eric W. Biederman
Cc: dedekind1, Marco Stornelli, Simon Kagstrom, linux-embedded, akpm,
dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <m1iqd8ptg9.fsf@fess.ebiederm.org>
On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
> David VomLehn <dvomlehn@cisco.com> writes:
>
> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> > ...
> >> Why not use the kdump hook? If you handle a kernel panic that way
> >> you get enhanced reliability and full user space support. All in a hook
> >> that is already present and already works.
...
> > 1. In what ways would this be better than, say, a panic_notifier?
>
> A couple of ways.
>
> - You are doing the work in a known good kernel instead of the kernel
> that just paniced for some unknown reason.
> - All of the control logic is in user space (not the kernel) so you can
> potentially do something as simple as "date >> logfile" to get the
> date.
I think I see better what you're suggesting--passing the info to a kdump
kernel and having it do whatever it wants. I don't think I want to do this,
but I haven't used any of the kexec() stuff, so I may be missing the point.
Some more context:
My application is an embedded one, and one of the big things I need to do
after a failure is to bring up a fully functional kernel ASAP. Once I have
that kernel, I process all of the crash data in user space concurrently with
running my main application. Because I'm embedded, I'm very limited in how
much crash data I can save over a reboot, how much I can store, and how
much I can send to a central collection point. This is good, since it doesn't
take up a lot of resources, but core dumps are out of the question.
As I understand kdump, I would also need to have a second kernel in memory
to do the kdump work. It wouldn't need to be as big is the kernel that
failed, but it would still require a significant amount of memory. On an
embedded system, the idle memory may be a luxury we can't afford.
I think this makes a kdump-based solution difficult, but if it can meet
my requirements, I'd much rather use it (I've been following kdump since
it's inception quite a few years ago, but it hasn't seemed a good match
for embedded Linux). Does this still sound like a good match?
> > 2. Where would you suggest tying in? (Particularly since not all architectures
> > currently support kdump)
>
> No changes are needed kernel side. You just need an appropriate kernel and
> initrd for your purpose.
I think I must still be missing something. I have dynamic data that I want
to preserve as I reboot from a failed kernel to a fresh new kernel. By
the time the fresh kernel starts init, the dynamic data (IP addresses, MAC
addresses) has been re-written with new values. This is why I'm trying to
preserve, but I may be running without disk or flash. This patch doesn't
preserve the data, but it gets it into the kernel so that it can be
preserved. At present, I'm preserving the data in a panic_notifier function,
but I am not wedded to that. At present, the data will be copied to a
section of memory retained across boots, but I know others will want to
write to flash.
> All of the interesting architectures support kexec, and if an
> architecture doesn't it isn't hard to add. The architecture specific
> part is very simple. A pain to debug initially but very simple.
I use MIPS processors, and it looks like it is supported. So long as it's
stable, I'm happy to use it.
> Eric
David VL
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Eric W. Biederman @ 2009-11-18 0:28 UTC (permalink / raw)
To: David VomLehn
Cc: dedekind1, Marco Stornelli, Simon Kagstrom, linux-embedded, akpm,
dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <20091117235627.GA13469@dvomlehn-lnx2.corp.sa.net>
David VomLehn <dvomlehn@cisco.com> writes:
> On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> ...
>> Why not use the kdump hook? If you handle a kernel panic that way
>> you get enhanced reliability and full user space support. All in a hook
>> that is already present and already works.
>
> I'm a big fan of avoiding reinvention of the wheel--if I can use something
> already present, I will. However, I'm not clear about how much of the problem
> I'm addressing will be solved by using a kdump hook. If I understand
> correctly, you'd still need a pseudo-file somewhere to actually get the data
> from user space to kernel space. *Then* you could use a kdump hook to
> transfer the data to flash or some memory area that will be retained across
> boots. Is this the approach to which you were referring? If so, I have a
> couple more questions:
>
> 1. In what ways would this be better than, say, a panic_notifier?
A couple of ways.
- You are doing the work in a known good kernel instead of the kernel
that just paniced for some unknown reason.
- All of the control logic is in user space (not the kernel) so you can
potentially do something as simple as "date >> logfile" to get the
date.
> 2. Where would you suggest tying in? (Particularly since not all architectures
> currently support kdump)
No changes are needed kernel side. You just need an appropriate kernel and
initrd for your purpose.
All of the interesting architectures support kexec, and if an
architecture doesn't it isn't hard to add. The architecture specific
part is very simple. A pain to debug initially but very simple.
Eric
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: David VomLehn @ 2009-11-17 23:56 UTC (permalink / raw)
To: Eric W. Biederman
Cc: dedekind1, Marco Stornelli, Simon Kagstrom, linux-embedded, akpm,
dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <m1pr7hf93s.fsf@fess.ebiederm.org>
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
> Why not use the kdump hook? If you handle a kernel panic that way
> you get enhanced reliability and full user space support. All in a hook
> that is already present and already works.
I'm a big fan of avoiding reinvention of the wheel--if I can use something
already present, I will. However, I'm not clear about how much of the problem
I'm addressing will be solved by using a kdump hook. If I understand
correctly, you'd still need a pseudo-file somewhere to actually get the data
from user space to kernel space. *Then* you could use a kdump hook to
transfer the data to flash or some memory area that will be retained across
boots. Is this the approach to which you were referring? If so, I have a
couple more questions:
1. In what ways would this be better than, say, a panic_notifier?
2. Where would you suggest tying in? (Particularly since not all architectures
currently support kdump)
> Eric
David VL
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Marco Stornelli @ 2009-11-17 17:53 UTC (permalink / raw)
To: dedekind1
Cc: Simon Kagstrom, David VomLehn, linux-embedded, akpm, dwm2,
linux-kernel, mpm, paul.gortmaker
In-Reply-To: <1258463404.27437.103.camel@localhost>
Artem Bityutskiy wrote:
> On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
>> 2009/11/17 Artem Bityutskiy <dedekind1@gmail.com>:
>
> We need to store this information of NAND flash. Implementing logs on
> NAND flash is about handling bad blocks, choosing format of records, and
> may be even handling wear-levelling. This is not that simple.
>
> And then I have match oops to the userspace environment prints, using I
> guess timestamps, which is also about complications in userspace.
>
Indeed my suggestion was to use a persistent ram, not difficult to use.
>>> This patch solves the problem gracefully, and I'd rather demand you to point what
>>> is the technical problem with the patches.
>>>
>> Simply because I think that we should avoid to include in the kernel
>> things we can do in a simply way at user space level.
>
> If it is much easier to have in the kernel, then this argument does not
> work, IMHO.
>
>> I think this
>> patch is well done but it's one of the patches that are solutions "for
>> embedded only", but it's only my opinion.
>
> Also IMHO, but having embedded-only things is not bad at all.
>
In the past other patches are not accepted in main line for this, maybe
you'll be luckier.
Marco
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-17 16:53 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Grant Likely, Mike Frysinger, linux-embedded
In-Reply-To: <4B02C5CF.2050102@billgatliff.com>
On Tuesday 17 November 2009, Bill Gatliff wrote:
> David Brownell wrote:
> >
> > It'd be purely for pinmux.
> >
>
> Ugh. That would be a tough interface to design.
True. That's part of why I object to wanting to combine
it with GPIOs ... or, combine everything else with GPIOs
too (like PWMs).
But Grant talks about wanting such things, and if he can
deliver it, more power to him.
> It makes me think of
> an old-time telephone switchboard, with an undefined number of wires and
> an equally-undefined number of plugs to insert them into.
>
> "Good morning, Mabel! Give me SCL1 on AA25 please! No, I don't know
> who SCL1 is nor where AA25 is. I'll be waiting."
"What? You're saying that I've got to take three other connections
at the same time? And cut these other two calls? No, I only wanted
to make that one call ..."
>
>
> :)
>
>
>
^ permalink raw reply
* Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: Bill Gatliff @ 2009-11-17 16:00 UTC (permalink / raw)
To: David Brownell; +Cc: linux-embedded
In-Reply-To: <200911170029.36669.david-b@pacbell.net>
David Brownell wrote:
> Worth highlighting that this is necessarily a "low quality"
> PWM ... in the sense that it's got lots of jitter because
> of needing CPU intervention in IRQ context, so it's subject
> to delays from both IRQs being blocked and from other timer
> driven activities firing first.
>
Very, very good point.
The jitter can be quite low (100's of usecs) on a 200 MHz ARM9 chip, in
fact, but you'll eat your battery alive if it's a portable device. And
the jitter will also destroy your waveform at high or low duty cycles.
> There are lots of applications where that jitter is enough
> to preclude using this kind of PWM. I get the feeling that
> some of the Linux folk seeing "this PWM thing" are not very
> cognizant of such issues ... they've not had to use PWM to
> do anything where the jitter matters. (Not that I have;
> but I know that such apps are a motivation for most of the
> PWM hardware on microcontrollers. A few PWMs plus some
> sensors, hall effect or QEI or whatever; then you get a
> motor controller.)
>
For some definitions of "motor controller". :)
You might even be able to use a GPIO-as-PWM signal to feed an R/C servo
positioner, but the jitter there will be very visual when it occurs.
Dimming control of LEDs and incandescent lamps can be very forgiving of
jitter, but I was thinking more along the lines of "make this LED blink
faster or slower" when I came up with the implementation.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-17 15:54 UTC (permalink / raw)
To: David Brownell; +Cc: Grant Likely, linux-embedded, Mike Frysinger
In-Reply-To: <200911170027.38664.david-b@pacbell.net>
David Brownell wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>
>> I'm concerned about the approach taken here. As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external signal line, just like GPIO lines.
>>
>
> PWM is not GPIO, and doesn't fit into a GPIO framework.
>
> Since *everything* boils down to one or more signal lines,
> your argument leads directly to Linux having no native
> hardware interface except GPIOs. Not ... practical. ;)
>
Wait. Isn't that what Ubicom's chips do? :)
> If you want to combine PWM with something else ... timers would
> be a better target. They're both fundamentally about periodic
> phenomena. And quite a lot of timers support PWM output modes...
>
> (A generic interface to hardware timers is lacking, too.)
>
True, and I have code (not yet published) to support a couple of
timer/counter peripherals under the PWM interface. So for that
functionality at least, I don't think a more generic or standalone API
is necessary.
I don't know how to define a generic interface for the counter a.k.a.
"input capture" behavior of such devices, though. Still an unsolved
problem, but I don't think it will be a part of the PWM API. It's a
different metaphor.
> GPIOs, on the other hand, are packaged for manual bit
> twiddling. While it's possible to create low-speed
> implementations of serial protocols using GPIOs (like
> 2-wire/I2C, one-wire, and various SPI variants), those
> are explicitly the high-overhead (and low performance)
> substitutes, to be used only when native hardware isn't
> available (or is broken etc).
>
And when using GPIO to generate I2C or SPI signals, you don't do it
through the GPIO interface--- you do it through the I2C or SPI
interface, and a driver behind that API talks to the GPIO API.... or to
a different driver if you change your mind. Same idea for the PWM API.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-17 15:48 UTC (permalink / raw)
To: David Brownell; +Cc: Grant Likely, Mike Frysinger, linux-embedded
In-Reply-To: <200911162347.02364.david-b@pacbell.net>
David Brownell wrote:
>
> It'd be purely for pinmux.
>
Ugh. That would be a tough interface to design. It makes me think of
an old-time telephone switchboard, with an undefined number of wires and
an equally-undefined number of plugs to insert them into.
"Good morning, Mabel! Give me SCL1 on AA25 please! No, I don't know
who SCL1 is nor where AA25 is. I'll be waiting."
:)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Eric W. Biederman @ 2009-11-17 15:45 UTC (permalink / raw)
To: dedekind1
Cc: Marco Stornelli, Simon Kagstrom, David VomLehn, linux-embedded,
akpm, dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <1258463404.27437.103.camel@localhost>
Artem Bityutskiy <dedekind1@gmail.com> writes:
> On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
>> 2009/11/17 Artem Bityutskiy <dedekind1@gmail.com>:
>> > Take a look at my mails where I describe different complications we have
>> > in our system. We really want to have an OOPS/panic + our environment
>> > stuff to go together, at once. This makes things so much simpler.
>> >
>> > Really, what is the problem providing this trivial panic-note
>> > capability, where user-space can give the kernel a small buffer, and ask
>> > the kernel to print this buffer at the oops/panic time. Very simple and
>> > elegant, and just solves the problem.
>> >
>> > Why perversions with time-stamps, separate storages are needed?
>> >
>> > IOW, you suggest a complicated approach, and demand explaining why we do
>> > not go for it. Simply because it is unnecessarily complex.
>>
>> I don't think it's a complicated approach we are talking of a system
>> log like syslog with a temporal information, nothing more.
>
> We need to store this information of NAND flash. Implementing logs on
> NAND flash is about handling bad blocks, choosing format of records, and
> may be even handling wear-levelling. This is not that simple.
>
> And then I have match oops to the userspace environment prints, using I
> guess timestamps, which is also about complications in userspace.
>
>> > This patch solves the problem gracefully, and I'd rather demand you to point what
>> > is the technical problem with the patches.
>> >
>>
>> Simply because I think that we should avoid to include in the kernel
>> things we can do in a simply way at user space level.
>
> If it is much easier to have in the kernel, then this argument does not
> work, IMHO.
>
>> I think this
>> patch is well done but it's one of the patches that are solutions "for
>> embedded only", but it's only my opinion.
>
> Also IMHO, but having embedded-only things is not bad at all.
Why not use the kdump hook? If you handle a kernel panic that way
you get enhanced reliability and full user space support. All in a hook
that is already present and already works.
Eric
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-17 15:45 UTC (permalink / raw)
To: Grant Likely; +Cc: Mike Frysinger, linux-embedded, David Brownell
In-Reply-To: <fa686aa40911132355t3b79fe46m90005ecba453dcc1@mail.gmail.com>
Grant Likely wrote:
>
> Common code is a big gain in and of itself.
I completely agree! Which is why I used the GPIO API in my PWM
pseudo-device, along with an hrtimer.
> What I would like to see is the PWM functions added to the GPIO API.
> GPIO drivers can then either implement them or not. If a GPIO driver
> supports the PWM function, great. If not, then it returns -EINVAL.
> Heck, I'll even got a driver right now that I'd use it with. I'm more
> than happy to help code it up even.
>
I think the appropriate thing to do in such cases is to reimplement the
GPIO driver at its lowest level to provide both GPIO API and PWM API
interfaces. In my way of thinking, such hardware is a kind of
multi-function device and it should be treated that way. No need to
expose that multi-functionality to the user unless necessary.
The odd case to me is the concept of "timed GPIO", as in the Android
kernels. I see the timing capability as a convenience feature that
could be realized by adding timers to the GPIO interface (as they did),
or by having a one-shot PWM channel. I'm not really comfortable with
either as an interface concept, however, because it just doesn't... feel
right. :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-17 15:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded, Mike Frysinger, David Brownell
In-Reply-To: <fa686aa40911131108o301efa1ew5c0ab31184aa7f75@mail.gmail.com>
Grant Likely wrote:
> Hi Bill
>
> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff <bgat@billgatliff.com> wrote:
>
>> This series implements a Generic PWM Device API, including reference
>> implementations for the Atmel PWMC device, an LED device, and an LED
>> trigger. It is based on linux-2.6.27.
>>
> [...]
>
>> The implementation of the Generic PWM Device API is structurally
>> similar to the generic GPIO API, except that the PWM code uses
>> platform bus_id strings instead of integers to identify target
>> deviices. A configuration structure is also provided, both to
>> facilitate atomic hardware state changes and so that the API can be
>> extended in a source-code-compatible way to accomodate devices with
>> features not anticipated by the current code.
>>
>
> Hey Bill,
>
> I'm concerned about the approach taken here. As I understand it, the
> PWM signals are very similar to GPIOs in that each PWM device controls
> an external signal line, just like GPIO lines. The difference being
> that PWMs cannot do input, and has additional capabilities (can be
> programmed with a signal; not just on/off/tristate). Actually, many
> GPIOs have these properties too. I've got a part with output-only
> gpios, and gpio devices that also have a PWM.
>
It's true that PWM signals can be emitted via GPIO pins, and in fact the
API code I submitted uses the GPIO API combined with an hrtimer to
generate a low-speed PWM output.
It's also true that things like LEDs might want to be driven by PWM
signals, and indeed LEDs can also be driven by GPIO pins.
Finally, it's accurate to say that a lot of microcontrollers multiplex
GPIO functions onto pins that also provide PWM functionality.
But in my opinion, none of the above means that the PWM API and GPIO API
should be coupled at the interface abstraction. All it means is that in
some cases, one implementation might be able to "stand in" as an
embodiment of the other's interface. And we all agree on that for PWM
and GPIO.
The reason I think that PWM merits its own API is because I want the
users of the interface to be able to treat it as a PWM-only metaphor.
Behind the scenes, we may in fact have a connection with the GPIO
interface--- and in fact we already do with my code. But PWM generation
can also come from timer/counter peripherals having a compare/match
capability, from true PWM generation hardware (which are in most cases
just three tightly-coupled timer/counters with compare/match hardware),
as well as from standalone chips that are controlled over an I2C or SPI
interface. The latter example is in fact the initial motivation for the
code, even though at the moment I don't have any patches available to
submit because the devices in question are 8-bit microcontrollers
running custom firmware.
Given a PWM-capable chip that you control over an I2C or SPI interface,
I don't think anyone would argue that such chips should be viewed as an
extension of the SPI or I2C APIs just because the chips use those
communications protocols. I think it's a similar argument for PWM and GPIO.
Overall, I think your question is a very good one and it's one that I
asked myself early on. And it's a question that we should ask for EVERY
new interface abstraction that's developed for kernel-facing or
application-facing users.
> What is the reason for bringing in an entirely new framework instead
> of extending the GPIO API or gpiolib? I'm not too excited about
> having two entirely different frameworks for what basically boils down
> to "numbered signal pins".
>
I hope my reasoning is clear. I might not be right, but at least you
know what my thoughts are. Questions, comments and flames welcome!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Artem Bityutskiy @ 2009-11-17 13:10 UTC (permalink / raw)
To: Marco Stornelli
Cc: Simon Kagstrom, David VomLehn, linux-embedded, akpm, dwm2,
linux-kernel, mpm, paul.gortmaker
In-Reply-To: <2ea1731b0911170445x13225c19w797388d2211de2d9@mail.gmail.com>
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
> 2009/11/17 Artem Bityutskiy <dedekind1@gmail.com>:
> > Take a look at my mails where I describe different complications we have
> > in our system. We really want to have an OOPS/panic + our environment
> > stuff to go together, at once. This makes things so much simpler.
> >
> > Really, what is the problem providing this trivial panic-note
> > capability, where user-space can give the kernel a small buffer, and ask
> > the kernel to print this buffer at the oops/panic time. Very simple and
> > elegant, and just solves the problem.
> >
> > Why perversions with time-stamps, separate storages are needed?
> >
> > IOW, you suggest a complicated approach, and demand explaining why we do
> > not go for it. Simply because it is unnecessarily complex.
>
> I don't think it's a complicated approach we are talking of a system
> log like syslog with a temporal information, nothing more.
We need to store this information of NAND flash. Implementing logs on
NAND flash is about handling bad blocks, choosing format of records, and
may be even handling wear-levelling. This is not that simple.
And then I have match oops to the userspace environment prints, using I
guess timestamps, which is also about complications in userspace.
> > This patch solves the problem gracefully, and I'd rather demand you to point what
> > is the technical problem with the patches.
> >
>
> Simply because I think that we should avoid to include in the kernel
> things we can do in a simply way at user space level.
If it is much easier to have in the kernel, then this argument does not
work, IMHO.
> I think this
> patch is well done but it's one of the patches that are solutions "for
> embedded only", but it's only my opinion.
Also IMHO, but having embedded-only things is not bad at all.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Marco Stornelli @ 2009-11-17 12:45 UTC (permalink / raw)
To: dedekind1
Cc: Simon Kagstrom, David VomLehn, linux-embedded, akpm, dwm2,
linux-kernel, mpm, paul.gortmaker
In-Reply-To: <1258447997.27437.76.camel@localhost>
2009/11/17 Artem Bityutskiy <dedekind1@gmail.com>:
> Take a look at my mails where I describe different complications we have
> in our system. We really want to have an OOPS/panic + our environment
> stuff to go together, at once. This makes things so much simpler.
>
> Really, what is the problem providing this trivial panic-note
> capability, where user-space can give the kernel a small buffer, and ask
> the kernel to print this buffer at the oops/panic time. Very simple and
> elegant, and just solves the problem.
>
> Why perversions with time-stamps, separate storages are needed?
>
> IOW, you suggest a complicated approach, and demand explaining why we do
> not go for it. Simply because it is unnecessarily complex.
I don't think it's a complicated approach we are talking of a system
log like syslog with a temporal information, nothing more.
> This patch solves the problem gracefully, and I'd rather demand you to point what
> is the technical problem with the patches.
>
Simply because I think that we should avoid to include in the kernel
things we can do in a simply way at user space level. I think this
patch is well done but it's one of the patches that are solutions "for
embedded only", but it's only my opinion.
Marco
^ permalink raw reply
* Re: [PATCH, RFC] panic-note: Annotation from user space for panics
From: Artem Bityutskiy @ 2009-11-17 9:03 UTC (permalink / raw)
To: David VomLehn
Cc: linux-embedded, akpm, dwm2, linux-kernel, mpm, paul.gortmaker
In-Reply-To: <20091112021322.GA6166@dvomlehn-lnx2.corp.sa.net>
A pair of nit-picks.
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
> @@ -0,0 +1,293 @@
> +/*
> + * panic-note.c
No need to type file name there.
> + *
> + * Allow a blob to be registered with the kernel that will be printed if
> + * the kernel panics.
> + *
> + * Copyright (C) 2009 Cisco Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +/* Open issues:
> + * Where should the panic_note file be created? It's almost like a sysctl,
> + * but doesn't follow the same rules. When you write to a sysctl file, the
> + * previous data is replaced. When you write to the panic_note file, you
> + * can append to the end of the existing data.
> + */
Please, take a look at what is the kernel comment style at
Documentation/CodingStyle. We use
/*
* Multi-line
* comment
*/
style.
> +
> +#include <linux/semaphore.h>
> +#include <linux/fs.h>
> +#include <linux/proc_fs.h>
> +#include <linux/module.h>
> +#include <linux/uaccess.h>
> +
> +/* Maximum size, in bytes, allowed for the blob. Having this limit prevents
> + * an inadvertant denial of service attack that might happen if someone with
> + * root privileges was automatically generating this note and the generator
> + * had an infinite loop. Perhaps this is more of a a denial of service
> + * suicide. */
> +#define PANIC_NOTE_SIZE (PAGE_SIZE * 4)
> +
> +/*
> + * struct panic_note_data - Information about the panic note
> + * @n: Number of bytes in the note
> + * @p: Pointer to the data in the note
> + * @sem: Semaphore controlling access to data in the note
> + */
> +struct panic_note_state {
> + size_t n;
> + void *p;
> + struct rw_semaphore sem;
> +};
> +
> +static struct panic_note_state panic_note_state = {
> + 0, NULL, __RWSEM_INITIALIZER(panic_note_state.sem)
> +};
> +static const struct file_operations panic_note_fops;
> +static struct inode_operations panic_note_iops;
> +static struct proc_dir_entry *panic_note_entry;
> +
> +/*
> + * panic_note_print - display the panic note
> + * @priority: Printk priority to use, e.g. KERN_EMERG
> + */
> +void panic_note_print()
> +{
> + int i;
> + int linelen;
int i, lineline is more compact.
> +
> + /* We skip the semaphore stuff because we're in a panic situation and
> + * the scheduler isn't available in case the semaphore is already owned
> + * by someone else */
> + for (i = 0; i < panic_note_state.n; i += linelen) {
> + const char *p;
> + int remaining;
> + const char *nl;
const char *p, *nl is more compact. And there are several more places.
But this is matter of taste, really.
> +
> + p = panic_note_state.p + i;
> + remaining = panic_note_state.n - i;
> +
> + nl = memchr(p, '\n', remaining);
> +
> + if (nl == NULL) {
> + linelen = remaining;
> + pr_emerg("%.*s\n", linelen, p);
> + } else {
> + linelen = nl - p + 1;
> + pr_emerg("%.*s", linelen, p);
> + }
> + }
> +}
> +
> +/*
> + * read_write_size - calculate the limited copy_to_user/copy_from_user count
> + * @nbytes: The number of bytes requested
> + * @pos: Offset, in bytes, into the file
> + * @size: Maximum I/O offset, in bytes. For a read, this is the actual
> + * number of bytes in the file, since you can't read past
> + * the end. Writes can be done after the number of bytes in the
> + * file, so this is the maximum possible file size, minus one.
> + *
> + * Returns the number of bytes to copy.
> + */
> +static ssize_t read_write_size(size_t nbytes, loff_t pos, size_t size)
> +{
> + ssize_t retval;
> +
> + if (pos >= size)
> + retval = 0;
> +
Unnecessary \n
> + else {
> + retval = size - pos;
> + if (retval > nbytes)
> + retval = nbytes;
> + }
> +
> + return retval;
> +}
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ 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