Hi!
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
Why is an entire filesystem needed, instead of simply a block driver
if the ramdisk driver cannot be used?
From documentation:
A relatively straight-forward solution is to write a simple block
driver for the non-volatile RAM, and mount over it any disk-based
filesystem such as
1. Disk-based filesystems such as ext2/ext3 were designed for optimum
performance on spinning disk media, so they implement features such
as block groups, which attempts to group inode data into a contiguous
set of data blocks to minimize disk seeking when accessing files. For
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so on. However this
limitations don't limit the fs itself because you must
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation as not
hard-link, only private memory mapping and so
On Mon 2009-06-22 20:07:06, Marco wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
How do you handle hard-links, then?
Indeed hard-links are not supported :) Due to the design of this fs
there are some limitations explained in the documentation
On Mon 2009-06-22 11:55:04, Tim Bird wrote:
Pavel Machek wrote:
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
Pavel Machek wrote:
I did not see that in the changelog. If it is not general purpose
filesystem, it is lot less interesting.
PRAMFS is not a general purpose filesystem. Please
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 with ext2.
Not if you want the RAM-based
On Mon 2009-06-22 23:57:53, 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
On Tue 2009-06-23 20:07:23, 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 into 13MB/sec disk. Hmm. I believe
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 into 13MB/sec disk. Hmm. I believe
If it loses power when doing atomic rename (to replace config files,
for example), it's likely that the whole /pramfs/configs/ directory
will be corrupt, because the rename is writing to the directory inode,
so you lose access to all names in that directory?
That sounds like it can't
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB of RAM:
Version 1.03e --Sequential Output--
On Sun 2009-06-28 19:33:02, Marco Stornelli wrote:
Pavel Machek wrote:
Ah now the write protection is a needed feature, in your previous
comment you talked about why not use ext2/3...
Marco
Just for your information I tried the same test with pc in a virtual
machine with 32MB
One of the things we're facing is Android, which has
its userspace in plain Java JNI at the end of this link:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34
1faa094c71922946fdab;hb=HEAD
If
to measure internal resistance. I know it is in
200mOhm to 400mOhm range, on my device. Is there easy way to measure
it more accurately?
Pavel
#!/bin/bash
#
# Copyright 2009 Pavel Machek pa...@ucw.cz, GPLv2
#
getval
Hi!1
Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)
Hardware is already given.
Well, Pavel attempts to implement a poor man's Coulomb counter or at
least
Hi!
+Challenges
+
+One of the difficulties in implementing a generic PWM framework is the
+fact that pulse-width-modulation applications involve real-world
+signals, which often must be carefully managed to prevent destruction
+of hardware that is linked to those signals. A DC motor that
+static void
+gpio_pwm_work (struct work_struct *work)
+{
+ struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
+
+ if (gp-active)
+ gpio_direction_output(gp-gpio, gp-polarity ? 1 : 0);
+ else
+ gpio_direction_output(gp-gpio, gp-polarity ?
+pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
+is stopped before it is released by the API.
free is normally used for something else. Rename to open/close?
... or request/release?
Works for me.
+pwm_start(), pwm_stop() -- Turns the PWM signal on and
11.02.2010, ? 23:58, Pavel Machek ???(?):
On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
Pavel Machek wrote:
+static void
+gpio_pwm_work (struct work_struct *work)
+{
+struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
+
+if (gp-active
Hi!
+But the disk-based fs over non-volatile RAM block driver approach has
+some drawbacks:
+
+1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4
+ were designed for optimum performance on spinning disk media, so they
+ implement features such as block groups,
On 07/01/2011 22:59, Tony Luck wrote:
On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli
marco.storne...@gmail.com wrote:
constraint). About the errors: pramfs does not maintain file data in the
page caches for normal file I/O, so no writeback, the read/write
operation are done with
Il 06/01/2011 19:22, Luck, Tony ha scritto:
Errata corrige: maybe I used the wrong term, I meant volatile instead
of temporary information, i.e. I'd like to save this info to re-read
it later but I don't want to store it in flash, a simple log, run-time
information for debug like a
24 matches
Mail list logo
