On Tuesday 14 April 2015 10:36:15 Rob Herring wrote:
4) Identifying additional people who should attend the device tree track.
Arnd Bergmann
Matt Porter
Jon Loeliger
Gaurav Minocha
Sorry, I won't be there. I should have replied earlier, but I'll be on
parental leave at the time
On Friday 04 May 2012, Mark Brown wrote:
Quite a few reference platforms (including Wolfson ones, which is why
I'm particularly interested) use replaceable modules to allow
configuration changes. Since we can often identify the configuration at
runtime we should ideally do that but currently
On Friday 04 May 2012, Wolfgang Denk wrote:
In message 201205041934.08830.a...@arndb.de you wrote:
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence
On Friday 04 May 2012, Wolfgang Denk wrote:
There are systems (and I bet it will be a growing number) where U-Boot
itself uses the DT for configuration. Also, there are functions that
are needed both by the boot loader and the kernel - for example to
dislay a splash screen the boot loader
On Thursday 22 December 2011, NeilBrown wrote:
If you created a 'logbuf' filesystem that used libfs to provide a single
directory in which privileged processes could create files then you wouldn't
need the kernel to know the allowed logs: radio, events, main, system.
The size could be set by
On Tuesday 27 September 2011 09:55:02 Håvard Skinnemoen wrote:
On Tue, Sep 27, 2011 at 5:13 AM, Arvid Brodin arvid.bro...@enea.com wrote:
[Resending with CC to affected parties]
Hi,
I would expect cache synchronization for DMA_TO_DEVICE and DMA_BIDIRECTIONAL
when dma_map_single() is
On Friday 09 September 2011, Artem Bityutskiy wrote:
On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
On Tuesday 06 September 2011, Artem Bityutskiy wrote:
Not sure about the bus approach - David, could you take a look at it
please? If we can handle errors there - then we could
On Tuesday 06 September 2011, Artem Bityutskiy wrote:
Not sure about the bus approach - David, could you take a look at it
please? If we can handle errors there - then we could indeed re-use the
UBI control device. We could even re-use the ioctl data structures for
UBI volumes creation/removal
On Thursday 25 August 2011, Artem Bityutskiy wrote:
On Wed, 2011-08-24 at 18:23 +0200, Arnd Bergmann wrote:
That should be fine, yes. I would probably put them into the same
header file though if they are in the same number space even
when you use them on distinct devices.
It does
On Monday 22 August 2011, Artem Bityutskiy wrote:
On Wed, 2011-08-17 at 15:17 +0200, david.wag...@free-electrons.com
wrote:
Questions:
==
I wasn't sure what magic ioctl number to use, so I settled to use the same
one
as a part of UBI: 'O', which was so far only used by UBI
On Tuesday 18 August 2009 21:07:01 Wolfgang Denk wrote:
Dear Arnd,
Josh Boyer suggested you might provide some insight...
I'm currently looking for a solution how to provide architecture
independent I/O accessor functions to U-Boot. In the past, lots of
code used direct pointer accesses,
On Tuesday 23 June 2009, David Woodhouse wrote:
And dd on /dev/mem would work, surely?
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
On Monday 22 June 2009, Marco wrote:
Sorry, I meant it's not currently possible. At the moment the only way
to use it as rootfs it's to copy all the data in an already mounted
(empty) ram partition and reboot. However it's not my first item on my
todo list because I think that it's possible
On Monday 22 June 2009, Jörn Engel wrote:
Four loops doing the same increment with different data types: long,
u64, we32 (wrong-endian) and we64. Compile with no optimizations.
Results on my i386 notebook:
long: 453953 us
we32: 880273 us
u64: 504214 us
we64:2259953 us
On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to
suggest
you
On Friday 22 August 2008, Jared Hulbert wrote:
This bytetable stuff looks overly complicated, both the data structure and
the access method. It seems like you are implementing your own custom
Huffman
compression with this.
Is the reasonn for the bytetable just to pack numbers
On Friday 22 August 2008, Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
| Unable to handle
On Friday 22 August 2008, Jared Hulbert wrote:
This implies for block devices that the entire filesystem metadata has to be
cached in RAM. This severely limits the size of AXFS filesystems when using
block devices, or the else memory usage will be excessive.
This is where 64bit squashfs
On Friday 22 August 2008, you wrote:
You mean to take this off list?
No, i replied to your mail that was sent just to me.
Putting everyone back on now
In 3, you create files with sysfs_create_file, and are fairly limited
with how you can use it. A structured file like you have in procfs
On Friday 22 August 2008, Phillip Lougher wrote:
1. Support for 4GB filesystems. In theory 2^64 bytes.
2. Compressed metadata
3. Inode timestamps
4. Hard-link support, and correct nlink counts
5. Sparse file support
6. Support for . .. in readdir
7. Indexed directories for fast lookup
On Thursday 21 August 2008, Jared Hulbert wrote:
1) same mount point -
I don't see how this works without an ioctl. I can't just make up
files in my mounted filesystem. You expect the mounted version to
match input to the mkfs. I'd not be happy with an ioctl. You can
just read it.
2)
On Thursday 21 August 2008, Jared Hulbert wrote:
The Kconfig edits and Makefiles required for AXFS.
Signed-off-by: Jared Hulbert [EMAIL PROTECTED]
If you split out this patch separate from the files, please make it the
*last* patch so that you cannot get build errors during a later git-bisect
On Thursday 21 August 2008, Jared Hulbert wrote:
+/* functions in other axfs files
**/
+int axfs_get_sb(struct file_system_type *, int, const char *, void *,
+ struct vfsmount *);
+void axfs_kill_super(struct super_block *);
+void
On Thursday 21 August 2008, David Woodhouse wrote:
On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote:
Exporting profiling data for a file system in another file system
(/proc) seems not very straigtforward to me. I think it is worth
considering to export this information via the
On Thursday 21 August 2008, Jared Hulbert wrote:
+ array_index = AXFS_GET_INODE_ARRAY_INDEX(sbi, ino_number);
+ array_index += page-index;
+
+ node_index = AXFS_GET_NODE_INDEX(sbi, array_index);
+ node_type = AXFS_GET_NODE_TYPE(sbi, array_index);
+
+ if
On Wednesday 02 July 2008, Denys Vlasenko wrote:
This patch fixes v850 architecture.
For all I know, v850 has been broken and unmaintained for a few years now,
didn't someone have a patch to remove it entirely?
Arnd
--
To unsubscribe from this list: send the line unsubscribe
On Thursday 03 July 2008, Andi Kleen wrote:
Same seems to be true for cris btw.
Cris has seen significant updates in 2.6.25 by its maintainer.
It's not a very active port, but skipping updates for one kernel
version is on a completely different scale from doing nothing
at all for over three
27 matches
Mail list logo
