2009/6/24 Jamie Lokier :
> Marco wrote:
>> > Second question: what happens if the system crashing _during_ a write
>> > to a file. Does it mean that file will fail it's checksum when it's
>> > read at the next boot?
>> >
>> > Maybe files aren't so important. What about when you write a file,
>> >
On Thu, 2009-06-25 at 14:27 +0800, Johnny Hung wrote:
> 2009/6/25 Benjamin Herrenschmidt :
> >
> >> Before the console is set up, the printk data is formatted
> >> and put into the kernel log buffer, but not sent to any console.
> >> Any messages printk'ed before that are buffered but do not
> >> a
2009/6/25 Benjamin Herrenschmidt :
>
>> Before the console is set up, the printk data is formatted
>> and put into the kernel log buffer, but not sent to any console.
>> Any messages printk'ed before that are buffered but do not
>> appear. When the console is initialized, then all buffered
>> mess
2009/6/24 Jamie Lokier :
> Pavel Machek wrote:
>> On Tue 2009-06-23 20:07:23, Marco wrote:
>> > You are talked about journaling. This schema works well for a disk, but
>> > what about a piece of ram? What about a crazy kernel that write in that
>> > area for a bug? Do you remember for example the e
2009/6/24 Pavel Machek :
> On Wed 2009-06-24 19:38:37, Marco wrote:
>> >>> Pavel Machek wrote:
>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
>> > Pavel Machek wrote:
>> >>> block of fast non-volatile RAM that need to access data on it using a
>> >>> standard filesytem interface."
> Before the console is set up, the printk data is formatted
> and put into the kernel log buffer, but not sent to any console.
> Any messages printk'ed before that are buffered but do not
> appear. When the console is initialized, then all buffered
> messages are sent to the console, and subsequ
Hi Alain,
I would like to test bzip2 and lzma compression on ARM.
Would you mind telling me what the status of your patches on ARM is, now
that the x86 and architecture independent code has been merged? Have
you or has anyone already updated them for 2.6.30, or shall I update
them by myself?
Th
On Wed 2009-06-24 19:38:37, Marco wrote:
> >>> Pavel Machek wrote:
> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> > Pavel Machek wrote:
> >>> block of fast non-volatile RAM that need to access data on it using a
> >>> standard filesytem interface."
> >> Turns a block of fast R
On Wed 2009-06-24 18:49:11, Marco wrote:
> >> Pavel Machek wrote:
> >>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> Pavel Machek wrote:
> >> block of fast non-volatile RAM that need to access data on it using a
> >> standard filesytem interface."
> > Turns a block of fast RAM int
Pavel Machek wrote:
> On Tue 2009-06-23 20:07:23, Marco wrote:
> > You are talked about journaling. This schema works well for a disk, but
> > what about a piece of ram? What about a crazy kernel that write in that
> > area for a bug? Do you remember for example the e1000e bug? It's not
>
> I beli
>>> Pavel Machek wrote:
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> Pavel Machek wrote:
>>> block of fast non-volatile RAM that need to access data on it using a
>>> standard filesytem interface."
>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>>
Marco wrote:
> > Second question: what happens if the system crashing _during_ a write
> > to a file. Does it mean that file will fail it's checksum when it's
> > read at the next boot?
> >
> > Maybe files aren't so important. What about when you write a file,
> > and then rename it over an exis
Arnd Bergmann wrote:
> On Wednesday 24 June 2009, Marco Stornelli wrote:
>>> Actually, reading from /dev/mem is only valid on real RAM. If the nvram
>>> is part of an IO memory mapping, you have to do mmap()+memcpy() rather
>>> than read(). So dd won't do it, but it's still easy to read from user
>
>> Pavel Machek wrote:
>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
Pavel Machek wrote:
>> block of fast non-volatile RAM that need to access data on it using a
>> standard filesytem interface."
> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
> better
On Wednesday 24 June 2009, Marco Stornelli wrote:
> > Actually, reading from /dev/mem is only valid on real RAM. If the nvram
> > is part of an IO memory mapping, you have to do mmap()+memcpy() rather
> > than read(). So dd won't do it, but it's still easy to read from user
> > space.
>
> For "sec
Hi,
Peter Korsgaard wrote:
> The input layer has serio infrastructure for this (E.G. for serial
> mice/touchscreens). Now, a speech codec doesn't have much to do with
> input devices, but it atleast clearly seperates the lowlevel uart
> communication from the speech codec handling.
>
> Have a loo
> "Stefan" == Stefan Schoenleitner writes:
Hi,
Stefan> There is the linux/drivers/char/atmel_serial.c driver which I
Stefan> could modify, so that it also includes the driver code for
Stefan> the speech codec. However, obviously that would be a really
Stefan> bad idea since it would dup
Stefan Schoenleitner wrote:
> It would be great if you could provide some links to documentation and
> example code.
I just found out that there are other kernel drivers using the serial
port as well (e.g. the SLIP or PPP drivers).
It seems that what I want to do (which is accessing the serial por
Hi,
I have a speech codec chip which uses SPI for high-speed PCM data and
UART for control/compressed speech packet transfer.
While I could write a userland device driver that just uses the ttySn
serial device, I would prefer to do that in kernel space since this is
where device drivers belong.
Th
19 matches
Mail list logo
