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&#
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 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 th
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 current
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
On Tuesday 27 September 2011 09:55:02 Håvard Skinnemoen wrote:
>
> On Tue, Sep 27, 2011 at 5:13 AM, Arvid Brodin 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 called,
On Friday 09 September 2011, David Wagner wrote:
> On 09/09/2011 01:53 PM, 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 - Davi
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 ha
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/remo
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 the
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 u
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 acce
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
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 u
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:225995
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 possi
On Monday 22 June 2009, Marco Stornelli wrote:
> > It's still a problem. You might be creating a file system image
> > for an embedded board with a different endianess.
>
> It's not possible to create an "image" with pramfs, it's like tmpfs.
But the data is persistant, you even support using it a
On Sunday 21 June 2009, Marco wrote:
> I was thinking about your comment and I think I'll use __kernel_off_t
> for the exported headers. I know that it will differ between 32 and 64
> bit architectures, but for this kind of fs there isn't any compatibility
> problem at layout level. You cannot remo
On Saturday 13 June 2009, Marco wrote:
> void __init mount_root(void)
> {
> +#ifdef CONFIG_ROOT_PRAMFS
> + if (MAJOR(ROOT_DEV) == MEM_MAJOR) {
> + if (mount_pramfs_root())
> + return;
> +
> + printk(KERN_ERR "VFS: Unable to mount root fs via
On Saturday 13 June 2009, Sam Ravnborg wrote:
> > + union {
> > + struct {
> > + /*
> > + * ptr to row block of 2D block pointer array,
> > + * file block #'s 0 to (blocksize/4)^2 - 1.
> > + */
> > +
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.
>
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 fas
On Friday 22 August 2008, Jared Hulbert wrote:
> > It certainly sounds like something for your medium-term TODO list,
> > although I wouldn't think of it as a show-stopper.
>
> Maybe. It more of a feature rather than a bug. It makes stat() and
> such fast. The trade off is RAM...
Yes. And if y
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, 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 sq
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 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 numbe
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
On Thursday 21 August 2008, Jared Hulbert wrote:
> So /sys/kernel/debug/axfs/volume0 would work?
>
> > 4) no profiling at all
> > The profiling code has certainly been useful to you during development,
> > and you should keep that code around for your own work on it,
> > but maybe you should not p
On Thursday 21 August 2008, Jared Hulbert wrote:
> > Have you seen any benefit of the rwsem over a simple mutex? I would guess
> > that you can never even get into the situation where you get concurrent
> > readers since I haven't found a single down_read() in your code, only
> > downgrade_write()
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.
On Thursday 21 August 2008, Jared Hulbert wrote:
> > One thing that would be really nice is if you could add fake-write
> > support in the way that I proposed for cramfs a few months ago.
> > This would make axfs much more interesting for another set of
> > users, and keep cramfs a really simple ex
On Thursday 21 August 2008, Nick Piggin wrote:
> On Thursday 21 August 2008 20:25, Carsten Otte wrote:
> > Jared Hulbert wrote:
> > > I'd like to get a first round of review on my AXFS filesystem.
> >
> > I like the general approach of it. It's much more flexible than the
> > ext2 extension I've do
On Thursday 21 August 2008, Jared Hulbert wrote:
> +static inline u64 axfs_bytetable_stitch(u8 depth, u8 *table, u64 index)
> +{
> + u64 i;
> + u64 output = 0;
> + u64 byte = 0;
> + u64 j;
> + u64 bits;
> +
> + for (i = 0; i < depth; i++) {
> + j =
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 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
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, Jared Hulbert wrote:
>
> +#ifndef __AXFS_H
> +#define __AXFS_H
> +
> +
> +#ifdef __KERNEL__
> +#include
> +#endif
> +#include
> +#include
> +
> +#define AXFS_MAGIC 0x48A0E4CD /* some random number */
> +#define AXFS_SIGNATURE "Advanced XIP FS"
> +#define
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-bi
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 year
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 linux-
41 matches
Mail list logo
