Re: [PATCH] PM: Hide CONFIG_PM from users
On Tue, Feb 08, 2011 at 12:05:40AM +0100, Rafael J. Wysocki wrote: > On Monday, February 07, 2011, Dmitry Torokhov wrote: > > More of an observation for your (b) justification. I'd probably force > > CONFIG_PM to always 'y'w while we weeding references to it from > > drivers... > > We simply can't force CONFIG_PM to 'y', because some platforms want it to be > 'n'. > > OTOH, if CONFIG_PM = CONFIG_PM_SLEEP||CONFIG_PM_RUNTIME, we can just leave the > #ifdefs as they are and simply avoid adding new ones, or use CONFIG_PM for all > PM callbacks. > For sh at least turning on CONFIG_PM without PM_SLEEP or PM_RUNTIME is largely pointless, so the bulk of the defconfigs have it turned off. The few platforms that do use CONFIG_PM for something also have more comprehensive support implemented. The few times we do have it enabled without one of the others supported is simply for build coverage, mostly due to sharing drivers (whatever isn't already triggered through rand/allyes/modconfigs). I would expect that this is a common scenario for the bulk of the defconfigs that reflect PM being a platform-specific vs architecture-wide property regardless of architecture, however. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v4] pramfs: headers
On Wed, Nov 24, 2010 at 09:23:02AM +0100, Marco Stornelli wrote:
> 2010/11/24 Paul Mundt :
> >> +#ifdef CONFIG_PRAMFS_WRITE_PROTECT
> >> +extern void pram_writeable(void *vaddr, unsigned long size, int rw);
> >> +
> >> +#define wrprotect(addr, size) pram_writeable(addr, size, 0)
> >> +
> >> +#else
> >> +
> >> +#define wrprotect(addr, size) do {} while (0)
> >> +
> >> +#endif /* CONFIG PRAMFS_WRITE_PROTECT */
> >> +
> > Perhaps this should be pram_wrprotect()? Does this really benefit from
> > being a config option instead of a mount option? Will this handle
> > multiple mounts with some write protected and others not?
>
> See my previous response.
>
Your previous response only alludes to why you didn't feel like making it
a mount option, and doesn't address any of the other questions.
> >
> >> +#ifdef CONFIG_PRAMFS_WRITE_PROTECT
> >> +static inline void pram_memunlock_range(void *p, unsigned long len)
> >> +{
> >> +#ifndef CONFIG_X86
> >> + ? ? local_irq_disable();
> >> +#endif
> >> + ? ? preempt_disable();
> >> + ? ? pram_writeable(p, len, 1);
> >> +}
> >> +
> > This needs some explaining, or killing. While the latter is preferable,
> > we can also work with the former.
> >
>
> Maybe I didn't understand, you mean preemt_disable() without disabling
> the interrupt?
I mean what exactly is this supposed to be doing? It looks pretty
questionable for SMP for starters, it doesn't explain why x86 is special,
etc. It looks like you wanted a spinlock with IRQs disabled but probably
opted not to use it because you were throwing this around interfaces that
could sleep, which looks like a really scary thing for latency. It's also
making architecture assumptions without any explanation of why. This
needs to be explained, and in some amount of detail, as it's not entirely
obvious.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/16 v4] pramfs: file operations
On Wed, Nov 24, 2010 at 09:11:13AM +0100, Marco Stornelli wrote: > 2010/11/24 Paul Mundt : > > most of this from ext2, I'm curious why you opted to hardcode this > > instead of maintaining the flexibility that ext2 XIP has over this. > > First of all because it was simpler :) In addition there was some > design problem to use it in combination with the memory protection. Do you have more details on this? You can easily check for unsupportable configurations with mount options and bail out accordingly. > The difference with ext2 is that we aren't talking about a general > purpose fs used (mainly) on normal desktop/server systems, but a > specific fs for embedded world, so I think some little constraints are > ok. > I'm not sure what your point is. It's not a general purpose file system, but that's not an excuse for taking shortcuts. Out of the boards on my desk, I have at least 3 that could make use of this file system where I could use both XIP and non-XIP for different stores out of the box. I wouldn't exactly call it a corner case. Also, as Tony's patch set demonstrates, these sorts of non-volatile data stores are common enough in the server space to make pramfs an option there, too. Please lose this mentality that because something was originally tasked for embedded it's perfectly acceptable to ship a crippled interface. As it is, this is something that will have to be rewritten one way or the other, but whether that happens in or out of staging/ is not such a big concern. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16 v4] pramfs: dir operations
On Sat, Nov 20, 2010 at 11:00:45AM +0100, Marco Stornelli wrote:
> +int pram_add_link(struct dentry *dentry, struct inode *inode)
> +{
> + struct inode *dir = dentry->d_parent->d_inode;
> + struct pram_inode *pidir, *pi, *pitail = NULL;
> + u64 tail_ino, prev_ino;
> +
> + const char *name = dentry->d_name.name;
> +
> + int namelen = dentry->d_name.len > PRAM_NAME_LEN ?
> + PRAM_NAME_LEN : dentry->d_name.len;
> +
namelen = min_t(unsigned int, dentry->d_name.len, PRAM_NAME_LEN);
?
> +#define S_SHIFT 12
> +static unsigned int dtype_by_mode[S_IFMT >> S_SHIFT] = {
> + [S_IFREG >> S_SHIFT]DT_REG,
> + [S_IFDIR >> S_SHIFT]DT_DIR,
> + [S_IFCHR >> S_SHIFT]DT_CHR,
> + [S_IFBLK >> S_SHIFT]DT_BLK,
> + [S_IFIFO >> S_SHIFT]DT_FIFO,
> + [S_IFSOCK >> S_SHIFT] DT_SOCK,
> + [S_IFLNK >> S_SHIFT]DT_LNK,
> +};
> +
> +static int pram_readdir(struct file *filp, void *dirent, filldir_t filldir)
> +{
...
> + ret = filldir(dirent, name, namelen,
> + filp->f_pos, ino,
> + dtype_by_mode[(be16_to_cpu(pi->i_mode) &
> S_IFMT)>>S_SHIFT]);
> + filp->f_pos = pi->i_d.d_next ? be64_to_cpu(pi->i_d.d_next) : 3;
You might try to provide some generic helpers for this, at least GFS2
also does the same thing:
include/linux/gfs2_ondisk.h:#define DT2IF(dt) (((dt) << 12) & S_IFMT)
include/linux/gfs2_ondisk.h:#define IF2DT(sif) (((sif) & S_IFMT) >> 12)
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16 v4] pramfs: headers
On Sat, Nov 20, 2010 at 11:00:15AM +0100, Marco Stornelli wrote:
> +/*
> + * Debug code
> + */
> +#define pram_dbg(s, args...) pr_debug("PRAMFS: "s, ## args)
> +#define pram_err(s, args...) pr_err("PRAMFS: "s, ## args)
> +#define pram_warn(s, args...)pr_warning("PRAMFS: "s, ## args)
> +#define pram_info(s, args...)pr_info("PRAMFS: "s, ## args)
> +
Please kill off all of this and just use KBUILD_MODNAME centrally.
> +#ifdef CONFIG_PRAMFS_WRITE_PROTECT
> +extern void pram_writeable(void *vaddr, unsigned long size, int rw);
> +
> +#define wrprotect(addr, size) pram_writeable(addr, size, 0)
> +
> +#else
> +
> +#define wrprotect(addr, size) do {} while (0)
> +
> +#endif /* CONFIG PRAMFS_WRITE_PROTECT */
> +
Perhaps this should be pram_wrprotect()? Does this really benefit from
being a config option instead of a mount option? Will this handle
multiple mounts with some write protected and others not?
> +#ifdef CONFIG_PRAMFS_WRITE_PROTECT
> +static inline void pram_memunlock_range(void *p, unsigned long len)
> +{
> +#ifndef CONFIG_X86
> + local_irq_disable();
> +#endif
> + preempt_disable();
> + pram_writeable(p, len, 1);
> +}
> +
This needs some explaining, or killing. While the latter is preferable,
we can also work with the former.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/16 v4] pramfs: file operations
On Sat, Nov 20, 2010 at 10:58:40AM +0100, Marco Stornelli wrote:
> diff -Nurp linux-2.6.36-orig/fs/pramfs/file.c linux-2.6.36/fs/pramfs/file.c
> --- linux-2.6.36-orig/fs/pramfs/file.c1970-01-01 01:00:00.0
> +0100
> +++ linux-2.6.36/fs/pramfs/file.c 2010-09-24 18:34:03.0 +0200
> @@ -0,0 +1,166 @@
> +/*
> + * FILE NAME fs/pramfs/file.c
> + *
> + * BRIEF DESCRIPTION
> + *
> + * File operations for files.
> + *
This FILE NAME / BRIEF DESCRIPTION thing should probably die, it's also
not used consistently throughout the series.
> +static int pram_open_file(struct inode *inode, struct file *filp)
> +{
> +#ifndef CONFIG_PRAMFS_XIP
> + /* Without XIP we force to use Direct IO */
> + filp->f_flags |= O_DIRECT;
> +#endif
> + return generic_file_open(inode, filp);
> +}
> +
Relying on a config option for this is in violently poor taste. Rely on
the config option to enable/disable XIP support as you like, but whether
it's actually mounted XIP or not should really depend be determined by a
mount option. Presently you have no way of dealing with the file system
being mounted multiple times with mixed XIP and non-XIP, which doesn't
seem like a particularly exotic configuration. As you seem to have copied
most of this from ext2, I'm curious why you opted to hardcode this
instead of maintaining the flexibility that ext2 XIP has over this.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A better way to sequence driver initialization?
On Sat, Apr 10, 2010 at 08:33:53PM -0500, Bill Gatliff wrote: > Grant Likely wrote: > > On Sat, Apr 10, 2010 at 5:39 PM, Paul Mundt wrote: > > > >> In cases where you can specifically note that dependencies, doing so will > >> save you a world of pain. Despite that, it's simply not possible to do > >> this as a free-for-all. Devices or busses that can tolerate multi-threaded > >> probing need to be converted over one at a time, but even then you still > >> need the dependency tracking for those that depend on link order today. > >> > > Who's to say a function like gpio_request_wait_for_it(GPIO_NUMBER, > "dependent-driver") isn't the way to do the dependency tracking? I > can't even implement that without a context that can sleep... > In some cases that might be valid, but there are many cases where drivers can reconfigure their capability sets based on which GPIOs are and aren't available. Just because a pin isn't available doesn't make it a show-stopper for the probe path.. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A better way to sequence driver initialization?
On Sat, Apr 10, 2010 at 08:35:41AM -0500, Bill Gatliff wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2010-04-09 at 14:23 -0500, Bill Gatliff wrote:
> >
> >> My recent post, "Requesting a GPIO that hasn't been registered yet", and
> >> Anton's reply thereto (thanks, Anton!) on linuxppc-dev got me thinking
> >> about the problem of dependencies between devices in different classes,
> >> and/or between drivers/devices in general. I'd like to float an idea to
> >> see if it's worth pursuing.
> >>
> >
> > I'd rather do things a bit more explicitely and less prone to break
> > existing stuff... something along the lines of, first defining a variant
> > of the initcalls to enable that "multithreaded" stuff, along with an
> > explicit wait_for_service("subsys:hid"); for example.
> >
> > One could also expose service deps via the module info, thus delaying
> > module init, or things like that (in fact, initcalls could even come
> > with a list of dependencies).
> >
>
> The general problem with your approach is that the module in question
> might not know what services it needs to wait for.
>
> Specific to my situation, the gpio-led code doesn't have any way of
> knowing that it needs to wait until my pca953x i2c devices have all been
> installed so that the gpio pin I have specified even exists. And short
> of setting up some kind of table in the board-specific code (or device
> tree, actually), I don't know how to communicate such a dependency
> without touching the generic gpio-led code--- which I'm trying to avoid.
>
This is a common problem for drivers that are all stuck on the same
initcall level and as a result are entirely dependent on link order. Some
more intelligent logic via the bus notifiers would help with some of
this, but it wouldn't help with drivers that are effectively unable to
probe for devices and that are entirely dependent on registration timing
to make sure that their backing device has become available.
You could also look at doing multi-threaded probing at the bus level
where the semantics and implications are better understood, but that
still doesn't necessarily help with ordering. (ie, registering a GPIO
expander on a PCI MFD before being able to bring up gpio-leds or
so). There has been past work for both multi-threading the probe routines
as well as constraining it and only doing it for things like PCI.
In cases where you can specifically note that dependencies, doing so will
save you a world of pain. Despite that, it's simply not possible to do
this as a free-for-all. Devices or busses that can tolerate multi-threaded
probing need to be converted over one at a time, but even then you still
need the dependency tracking for those that depend on link order today.
Vendors often end up doing this sort of work for device-specific kernels
where the underlying set of drivers is fixed, so there are also some
alternative approaches you can investigate there (OLPC comes to mind).
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: How to store kernel panic/oops
On Mon, Dec 28, 2009 at 07:03:48PM +0100, Marco Stornelli wrote: > David Woodhouse wrote: > > > Can't it be done with what's in the tree already? Just create an MTD > > device using phram or something else, then point mtdoops at it > > Yes of course, if possible we shouldn't reinvent the wheel but I > wondered if there was something more specific. To add mtdoops (more or > less 1k) we have to add mtd subsys (more or less 14k) to the kernel to > achieve this and it's all overhead. > panic/oops information is punted down to a kmsg dumper, which mtdoops just happens to be one of. If you wanted to do your own platform specific hack for size constraints you could easily just have your own special one instead. Take a look at linux/kmsg_dump.h. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Wed, Jul 22, 2009 at 11:22:59PM -0700, Andrew Morton wrote: > On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming > wrote: > > > On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote: > > > Andrew Morton wrote: > > > > > >> Until and unless someone else steps up I can act as maintainer of last > > >> resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, > > >> gpio, i2o and about 1000 other identifiable subsystems. > > > > > > If no-one else is helping out, Im happy to also be CC'd on MMC patches. > > > > > > > Ditto. > > Thanks, guys. > > I actually already have a little pile of MMC things queued: > > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch > http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch > > I guess we own them now ;) While you're in MMC collection mode: http://lkml.org/lkml/2009/7/17/75 wants to be queued, too. Presumably Ian will get to it at some point, though. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of bzip2 and lzma kernel compression for ARM?
On Thu, Jun 25, 2009 at 05:24:59PM +0200, Michael Opdenacker wrote: > On 06/25/2009 11:04 AM, Florian Fainelli wrote: > > Le Thursday 25 June 2009 10:56:45 Mike Rapoport, vous avez ?crit : > >> I'm not sure what exactly do you mean by "test bzip2 and lzma compression > >> on ARM", but if you refer to internal initramfs compression, I can tell > >> that I've used lzma compression on PXA270 and it works fine. > >> > > > > I think Michael refers to the lzma decompressor which allows you to use a > > lzma-compressed kernel as a (b)zImage with its architecture specific > > decompressor piggy-backed in the (b)zImage. > > > > Such thing would also be very useful on MIPS and PowerPC as well. > > > Yes, that's what I meant: using a bzip2 or lzma compressed kernel. I > would like to know the boot time impact on an ARM board. > > If I don't get any answer from Alain in the next days, I will propose a > patch update for ARM. > It's possible to use this generically now, yes. Anything building uImages today can basically wire it up in a similar fashion to how blackfin has and support it out of the box. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote: > > On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: > > >On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: > >>One topic that was partially touched on was dealing with various > >>memories on embedded systems. We have several sram based allocators > >>in the kernel for various different arch's: > >> > >>- Blackfin sram allocator arch/blackfin/mm/sram-alloc.c > >>- Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c > >>- AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ > >>avr32/mach-at32ap/include/mach/sram.h > >>- Potential davinci sram allocator > >> > >>There maybe others. > >> > >SH does this through NUMA on SRAM blocks that are anywhere from > >128kB to > >64MB. Some of our SMP configurations have upwards of a dozen of these > >blocks. > > Do you really have that much on chip memory? > Is this really a serious question? If we didn't, I would not have mentioned it. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
On Thu, Jun 18, 2009 at 08:24:35AM +0200, Marco Stornelli wrote: > 2009/6/18 Paul Mundt : > > H8300 is a nommu platform, so it has no TLB to flush. Yoshinori Sato is > > the maintainer. Consult the MAINTAINERS file, that's what it is there for. > > I know the MAINTAINERS file but for h8300 there isn't an exactly > indication (/arch/h8300 as for the other archs). > The file patterns are a new thing, I guess not all of the platforms were updated. In any event: UCLINUX FOR RENESAS H8/300 (H8300) P: Yoshinori Sato M: ys...@users.sourceforge.jp W: http://uclinux-h8.sourceforge.jp/ S: Supported Which is basically the first thing you find when looking for H8. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 09:42:46AM +0300, Mike Rapoport wrote: > James Bottomley wrote: > > We've got to the point where there are simply too many embedded > > architectures to invite all the arch maintainers to the kernel summit. > > So, this year, we thought we'd do embedded via topic driven invitations > > instead. So what we're looking for is a proposal to discuss the issues > > most affecting embedded architectures, or preview any features affecting > > the main kernel which embedded architectures might need ... or any other > > topics from embedded architectures which might need discussion or > > debate. > > Another issue that affects embedded architectures is drivers initialization > order. There are a lot of cases when you need the drivers to be initialized in > particular order, and current initcalls scheme does not allow fine grained > control for it. > Look at the early platform device abstraction, this allows specific fine-grained control over when certain drivers are initialized, well before the driver core is available. On SH this is how we deal with our system timers as clockevents/clocksources while just using regular platform devices, and having no other abstraction. You can read more in Documentation/driver-model/platform.txt. For an example, you can grep for earlytimer in arch/sh as well as in drivers/clocksource. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
On Wed, Jun 17, 2009 at 06:58:00PM +0200, Marco wrote: > Jared Hulbert wrote: > > > Why not just fix flush_tlb_range()? > > > > > > If an arch has a flush_tlb_kernel_page() that works then it stands to > > > reason that the flush_tlb_kernel_range() shouldn't work with minimal > > > effort, no? > > > > flush_tlb_kernel_page() is a new one to me, it doesn't have any mention > > in Documentation/cachetlb.txt anyways. > > > > Many of the flush_tlb_kernel_range() implementations do ranged checks > > with tunables to determine whether it is more expensive to selectively > > flush vs just blowing the entire TLB away. > > > > Likewise, there is no reason why those 4 architectures can not just shove > > that if (end <= start + PAGE_SIZE) check in the beginning of their > > flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for > > those cases. Hiding this in generic code is definitely not the way to go. > > Ok I'll change that function at arch level and I'll remove the ifdef, > I'll call only flush_tlb_kernel_page(), but I'd like to know what is > the opinion of the arch maintainers to do that. (Who is the maintainer > of H8300 arch?) > No, you should call flush_tlb_kernel_range() and just fix up the flush_tlb_kernel_range() calls to wrap in to flush_tlb_kernel_page(). As far as the kernel is concerned, flush_tlb_kernel_page() is not a standard interface, as it has no mention in Documentation/cachetlb.txt. flush_tlb_page() and flush_tlb_kernel_range() on the other hand are both standard interfaces. H8300 is a nommu platform, so it has no TLB to flush. Yoshinori Sato is the maintainer. Consult the MAINTAINERS file, that's what it is there for. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: > One topic that was partially touched on was dealing with various > memories on embedded systems. We have several sram based allocators > in the kernel for various different arch's: > > - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c > - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c > - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ > avr32/mach-at32ap/include/mach/sram.h > - Potential davinci sram allocator > > There maybe others. > SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write protection
On Tue, Jun 16, 2009 at 07:35:24PM -0700, Jared Hulbert wrote:
> > +/* init_mm.page_table_lock must be held before calling! */
> > +static void pram_page_writeable(unsigned long addr, int rw)
> > +{
> > + ? ? ? pgd_t *pgdp;
> > + ? ? ? pud_t *pudp;
> > + ? ? ? pmd_t *pmdp;
> > + ? ? ? pte_t *ptep;
> > +
> > + ? ? ? pgdp = pgd_offset_k(addr);
> > + ? ? ? if (!pgd_none(*pgdp)) {
> > + ? ? ? ? ? ? ? pudp = pud_offset(pgdp, addr);
> > + ? ? ? ? ? ? ? if (!pud_none(*pudp)) {
> > + ? ? ? ? ? ? ? ? ? ? ? pmdp = pmd_offset(pudp, addr);
> > + ? ? ? ? ? ? ? ? ? ? ? if (!pmd_none(*pmdp)) {
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_t pte;
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ptep = pte_offset_kernel(pmdp, addr);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = *ptep;
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (pte_present(pte)) {
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = rw ? pte_mkwrite(pte) :
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_wrprotect(pte);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_pte(ptep, pte);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> > + ? ? ? ? ? ? ? ? ? ? ? }
> > + ? ? ? ? ? ? ? }
> > + ? ? ? }
> > +}
>
> Wow. Don't we want to do this pte walking in mm/ someplace?
>
> Do you really intend to protect just the PTE in question rather than
> the entire physical page, regardless of which PTE is talking to it?
> Maybe I'm missing something.
>
follow_pfn() ought to be fine for this, optionally follow_pte() could be
exported and used.
> > +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300)
> > || \
> > + ? ? ? defined(CONFIG_BLACKFIN)
> > + ? ? ? /*
> > + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(),
> > + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal
> > + ? ? ? ?* to use _range() because many archs just flush the whole TLB.
> > + ? ? ? ?*/
> > + ? ? ? if (end <= start + PAGE_SIZE)
> > + ? ? ? ? ? ? ? flush_tlb_kernel_page(start);
> > + ? ? ? else
> > +#endif
> > + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end);
> > +}
>
> Why not just fix flush_tlb_range()?
>
> If an arch has a flush_tlb_kernel_page() that works then it stands to
> reason that the flush_tlb_kernel_range() shouldn't work with minimal
> effort, no?
flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
in Documentation/cachetlb.txt anyways.
Many of the flush_tlb_kernel_range() implementations do ranged checks
with tunables to determine whether it is more expensive to selectively
flush vs just blowing the entire TLB away.
Likewise, there is no reason why those 4 architectures can not just shove
that if (end <= start + PAGE_SIZE) check in the beginning of their
flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
those cases. Hiding this in generic code is definitely not the way to go.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 11:18:03AM +0100, Sam Ravnborg wrote: > On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote: > > On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg wrote: > > >> There are several other packages which are broken for embedded > > >> architectures, which I will hopefully attempt to fix by submitting > > >> patches > > >> upstream. But this is why we should be cautious about including new tools > > >> for compiling the kernel. Sam Ravnborg was correct in that a C program > > >> to do > > >> the work would be the proper way. But by not addressing a currently > > >> existing > > >> problem with an adequate replacement with something that does not exist > > >> currently, seems faulty. > > > > > > Why are "make headers_install" such a crucial thing for your > > > embedded environmnet? > > > > Sanity check. If the environment cannot replicate itself, then > > something has been faulty in the cross-compiling stage, that was used > > to propagate a native environment for the target architecture. > > So you actually build your target toolchain on your target? > This happens in a lot of places, like embedded gentoo ports, where almost all of the work is sent across distcc to a cross-compilation machine. In systems that use package management, it is done on the host through emulation, or painfully cross-compiled. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt wrote: > > I will repeat, there has not been a single coherent argument against what > > makes perl inherently incapable of being supported. > > You're right, this thread is worthless with that particular mindset, > Paul. Not, perhaps that the tool in question is brittle, and prone to > potentially break on more architectures than the current make and C > code infrastructure, no, your stance is, unless Perl *cannot* run on > that particular architecture and environment, it has a valid place in > the kernel because it was chosen by certain developers. > Nonsense. I singled out that point because that was the one you were replying to in the first place. I itemized the objections in this thread earlier on and attempted to indicate why they were not applicable in this context, and asked people to add to it if anything had been overlooked. If you want to play semantics, do it somewhere else. If the tool is brittle and constantly breaking, we will see bug reports, and re-evaluate the support position. This hasn't happened to date in the context of the kernel build system, so there is no point in even bringing this up. Anyways, given that you haven't contributed anything to the kernel and are therefore perhaps unfamiliar with how things work, I attempted to show you why the kernel made the decision it did and what it would take to change that. You have from the beginning only wanted to focus on idle semantics and refused to re-evaluate your own position on what precisely it is you find to be problematic in the first place. So, with that, I am done with this thread, and it seems the key takeaways from this entire thing has only been a few new lines in my killfile. It's regrettable you didn't get anything else out of this thread, though I think both the kernel and embedded linux will survive. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 03:18:53AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt wrote: > > Paul: > I initially wrote a rather details response to your e-mail. But > instead, I shall quote a previous e-mail of yours: > > > I will repeat again that no one has provided a > > _single_ reason for why they are unable to provide perl within their > > constrained environment. Until that happens, this entire thread is a > > joke. > > And I did so. And you have disregarded it. That makes me question the > logic of your fervent vehemence against such "Perl is perhaps not a > good idea in the kernel build infrastructure" people like myself. > You have done no such thing. You have provided an example as to why you personally find perl objectionable, and in your previous mail you even noted that you have patches for perl to fix the build issues, so there is no fundamental reason why you are _unable_ to provide perl in your environment. It all comes down to the fact you don't want to be bothered to put the effort in to getting perl setup in your environment, which quite frankly is no one's problem but your own. Personally I think perl (and python for that matter) is a terrible language and I wouldn't use it for anything of consequence, but again, that is my personal opinion and has nothing to do with regards to the build system and whether it was the better tool for the job as perceived by the people that elected to implemented infrastructure using it. I choose not to use it for my own projects, but I have no qualms with those that do. The kernel does not need to provide justification for every change that goes on as long as there is a reasonable attempt not to break things for other people. The onus is (and always has been) on you to demonstrate why perl is an unreasonable dependency to push on embedded developers, and you have failed utterly at demonstrating this in any sort of coherent fashion. I will repeat, there has not been a single coherent argument against what makes perl inherently incapable of being supported. Every single thing you have presented as a rebuttal has been your personal preference, which in this case is simply irrelevant. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 09:36:58PM -0600, Mark A. Miller wrote: > Actually, something that has amused me during this discussion, is that > right now, the latest stable Perl (5.8.8) does not compile correctly > on a uclibc host, which is typically what you want for embedded > systems, which is why you'd bother to cross compile. (Albeit I was > doing this natively under QEMU with a gcc/uclibc toolchain). > > I'll have a patch submitted upstream shortly, but basically the > hints/linux.sh assumes *obviously* you're linking to glibc. I've made > that less libc dependent, looking for either glibc or uclibc. > There are plenty that ship with glibc, too. What you "want" for embedded systems depends entirely on the application for the device, not general hand-wavy assertions. We (Renesas) ship BSPs on both precisely because of this reason, and eglibc will probably factor in at some point later on too. > So without patching Perl, by adding it to the kernel configuration, > it's broken being able to compile the kernel on most embedded > architectures. > This again has nothing to do with the kernel and everything to do with your distribution. I use perl on uclibc natively just fine, it is possible there are patches that have not been merged upstream, but this is again an entirely separate issue. You seem to be confusing the fact that people who build distributions and people who use them are one and the same, whereas "most" embedded developers are going to be using pre-built distributions provided with their reference hardware, and locking it down during productization. The fact you are doing a distribution aimed at embedded devices is nice, but do not try to push off problems you run in to that have a reasonable expectation of working everywhere else on to the kernel community as something we ought to care about. If you need to use a different libc on your platform, yes, you will have to update packages for this. This used to be true for gcc and other packages as well, but those were all fixed over time. The fact perl still stands out despite there being patches available is simply an indicator that folks working in that area haven't been very proactive in getting their changes merged upstream. Tough. This is now entirely off-topic and has nothing to do with the kernel any more. Please take this to the uclibc or perl lists instead. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sat, Jan 03, 2009 at 08:06:47PM -0600, Rob Landley wrote: > On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote: > > Leon Woestenberg wrote: > > > I agree with Rob that the amount of required dependencies should be > > > kept to a minimum. > > > > > > If we only use 0.5% of a certain language (or: dependent package), > > > then rather implement that 0.5% in the existing language. > > > > > > Dependencies very quickly become dependency hell. If A requires B, > > > then A also inherits all (future) requirements of B, etc. etc. > > > > > > In my daily software development work with Linux and GNU software in > > > general, 10% of it is spent fighting/removing these extremely "thin" > > > or false depencies, so that it is usuable in embedded devices. > > > > First of all, I largely consider this a joke. > > Yes, I've noticed this. The fact multiple other people do _not_ consider > this > a joke doesn't seem to have sunk in yet. > Let's look at the rationale presented so far in this thread: 1 - Being able to build the kernel natively on a constrained target is useful, regardless of whether it is being used for regression/stress testing or for headers installation or whatever else. 2 - Cross-compiling perl is hard. 3 - Some oddly constrained target distributions manage to ship with an entire toolchain yet fail to provide any implementation of perl. 4 - It wasn't required before. If there is anything I missed, feel free to add it to the list. It was difficult to extract even those 4 from the ranting. #1 is a logical fallacy. If you have enough space and CPU power and complete build environment to crunch away at the kernel for stress testing natively, you can do the same with building perl and negating point #2. This is especially true for NFS root filesystems where one is not space constrained during the development phase. #2 is another byproduct of your environment and generally a non-issue. There are plenty of options around having to cross-compile perl, and for those that still insist on doing so, people have been doing it long enough to be aware of the pitfalls involved. It is not a pleasant experience, but that is again entire your problem and entirely constrained to your environment. #3 seems to have come up a surprising number of times, and again seems to originate from the fact that no one wants to be bothered with #2 whilst putting together their oddly constrained rootfs. So far no one has actually posted any coherent rationale as to why these distributions are shipping with a full gcc/binutils/etc. environment yet are unable to supply perl. Obviously size is not a factor if it ships with a full build environment otherwise, so this suggests that the only logical objection to fixing up the distributions stems from #4. As far as #4 goes, I have a hard time seeing why this should be anyone's problem. Progress is not made by restricting people to the way things were, progress is made by adapting to new things as they come along. In the case of the perl scripts provided, perl was picked by the developer in question as the right tool for the job, and things generally went along pretty smoothly. Given that one has a reasonable expectation of perl being available on the vast majority of systems today, this is hardly an unrealistic tool to leverage for use within the kernel scripts. The perl dependency has never been an issue for me on any of the platforms I routinely work on, ranging from tiny microcontrollers to multi-node NUMA and SMP configurations and everything in between. In places where the target is capable of building natively, I have no qualms with building a reasonable development environment. And in places where builds are unrealistic, I will do them on the host instead. This has always been the way things were, and I find the implication that the majority of the embedded development community sits fixedly on #3 to be completely ridiculous. I will repeat again that no one has provided a _single_ reason for why they are unable to provide perl within their constrained environment. Until that happens, this entire thread is a joke. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote: > On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote: > >Misguided rhetoric aside, what does this actually accomplish? If folks > >add meaningful tools in to the kernel that require python, and it is > >generally regarded as being fairly ubiquitous, I can't imagine there > >being any substantiated objections against it. > > And if the said meaningful tools introduce complex dependencies, then > there should be an open discussion as to why exactly we need those > tools as opposed to a simpler implementation. > Complex is relative, something that is fairly ubiquitious can hardly be labelled as complex, regardless of whether historically people have had issues with that dependency in certain spaces. In any event, simplifying things is always good, but this open discussion thing is pure fancy, since when was the kernel a democracy? > >Your main reasons against inclusion of perl seem to be that there is > >no realistic expectation for target systems that will be self-hosting > >will have perl included, or the inherent complexity in maintaining a > >coherent cross compiling environment. Both of these things are issues > >with your own environment, and in no way are these representative of > >the embedded development community at large. > > I feel that if you attempted to look for discussions on "cross- > compiling perl", you will meet with a variety of complaints on what a > nightmare it is to do so in a sandboxed environment. > I've had to deal with cross compiling perl for over a decade, in all of its various forms, in all manner of embedded applications, so please tell someone who cares. There are various options around this headache today, as there have been for ages (though the options these days are rather less painful), and if you felt like attempting to look for discussions on those rather than trying to push this silly matter perhaps you might come up with something. The key thing you hit on is that there are a variety of complaints, and that is all they have ever been. If your system is so constrained, you shouldn't be doing builds on it in the first place. You certainly won't be able to build anything in your crippled environment outside of some simple applications anyways, this isn't a valid technical reason for keeping the kernel a policy stranglehold. > >Now with that out of the way, this entire series fundamentally fails > >to convert half of the perl scripts shipped with the kernel today, > >some that are required for build depending on Kconfig options, > [snip] > From what I can tell, it allows one to fully build the Linux kernel > without Perl. Wrong, re-read what I said and try again. > >Ignoring the compile-time dependencies that you overlooked, what you > >define as "development and debugging" scripts are still an integral > >part of the system, unless you are trying to argue that embedded > >developers have no interest in things like checkstack due to the > >trouble of trying to get perl built. > > Do I need that to compile a kernel? No. > Compile-time dependencies you do, yes. > Perl was not required to build the Linux kernel. Now it is. It adds > another dependency to the Linux kernel. Requiring bash is far less a > dependency that Perl is. > Perhaps so, but that is largely irrelevant. Moving off of the bash dependency is a lot more trivial than moving off of the perl one. The kernel bashisms are fairly marginal, and if someone were to do the leg work for that, it might even be accepted. Getting rid of perl is an uphill battle for no visible gain. People will continue to write and add scripts both in bash and perl on a routine basis regardless. > >The kernel is and always has been about using the right tool for the > >job, not a matter of dictating what tools you must use in order to > >accomplish a task you are interested in. Common sense does apply here > >though, so this might be a more daunting task for some than others. > > How is Perl a better tool for the job than what currently bash and > other standard utilities already offer? > How is bash a better tool for than job than what sed and posix shell already offer? Yes, we can reduce our dependencies to the bare minimum, but that is not constructive for the folks that are actually writing the scripts in the first place. Likewise, this is not even a real problem in the embedded developer demographic, the only place this is a problem is in specially stripped distributions or people that don't want to go through the pain of cross compiling perl. None of which is of any concern. If people are going to write useful things that are reasonably expected to be standard on build machines, ther
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote: > Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) > building a Linux kernel never required perl to be installed on the build > system. (Various development and debugging scripts were written in perl and > python and such, but they weren't involved in actually building a kernel.) > Building a kernel before 2.6.25 could be done with a minimal system built > from > gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing > else. (Embedded developers creating clean cross compile environments that > won't leak bits of the host system into the target, or bootstrapping native > development environments to run on target hardware or under emulators, tend > to > care about this sort of thing.) > > The perl checkin for 2.6.25 was the camel's nose under the tent flap, and > since then two more instances of perl have shown up in the core kernel build. > > This patch series removes the three required to build a basic kernel for qemu > for the targets I've tested (arm, mips, powerpc, sparc, m68k, sh4, and of > course x86 and x86-64), replacing them with shell scripts. Misguided rhetoric aside, what does this actually accomplish? If folks add meaningful tools in to the kernel that require python, and it is generally regarded as being fairly ubiquitous, I can't imagine there being any substantiated objections against it. Your main reasons against inclusion of perl seem to be that there is no realistic expectation for target systems that will be self-hosting will have perl included, or the inherent complexity in maintaining a coherent cross compiling environment. Both of these things are issues with your own environment, and in no way are these representative of the embedded development community at large. Now with that out of the way, this entire series fundamentally fails to convert half of the perl scripts shipped with the kernel today, some that are required for build depending on Kconfig options, and others that are simply useful tools for self-hosted environments. Simply converting a couple of scripts over you find objectionable is certainly fine if there is a real benefit in doing so, but this doesn't actually accomplish your goal of removing the perl dependency. Ignoring the compile-time dependencies that you overlooked, what you define as "development and debugging" scripts are still an integral part of the system, unless you are trying to argue that embedded developers have no interest in things like checkstack due to the trouble of trying to get perl built. Until you can post a series that converts all of scripts/*.pl in its entirety, you have failed to address the fundamental reason why perl is used in the first place. Trying to toss bizarre policy statements around regarding things you personally find objectionable without any coherent technical argument to the contrary is of no constructive use whatsoever. The kernel is and always has been about using the right tool for the job, not a matter of dictating what tools you must use in order to accomplish a task you are interested in. Common sense does apply here though, so this might be a more daunting task for some than others. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
On Mon, Oct 20, 2008 at 01:55:41PM +0200, Marco Stornelli wrote: > I quite agree with Ben and Christian. I think UIO drivers are usable for > simple devices, I think they aren't mature (will it ever be?) to use it > with complicated devices or with strict requirement. > This is a party line that has been parroted around a lot but doesn't really have a lot of validity. UIO drivers are usable for situations where the kernel-side handling of the device can be trivialized but still remains a necessary component in the device support (other than IRQ control, there is also the issue of setting up buffers and so on). A good example of this is platforms that push their multimedia codecs and blocks down through UIO. The reason for this is that there is a lot of complexity, requisite support code, and general overhead associated with supporting these blocks, most of which simply does not belong anywhere in the kernel, even though the kernel still has to do some degree of device support. UIO drivers are second class citizens in general, but the argument that they only apply to simple devices is simply incorrect. Things like uio_pdrv_genirq exist today which already allow for interrupt control through userspace, for example. You can grep for the uio_pdrv_genirq in-tree users to see examples of how this is used in the aforementioned case today. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 08:59:08AM -0500, Bill Gatliff wrote: > There isn't a lot of traffic on linux-embedded, and I'm not sure how many > people > who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is > huge, so I don't know how many hardcore embedded developers I would encounter > there. I was hoping for a round of feedback at a lower level before pushing > anything upstream like that. > This isn't your problem. If people are interested in general embedded topics, they should be subscribed to the list. If they aren't, it's their loss. Cross posting to every potentially relevant list is a complete waste of time, and only helps to split out the discussion so nothing actually gets accomplished in a centralized location. > Hasn't been a problem so far. I posted the first version of the code on > l-a-k, > and got some feedback on the pwm_device API and a lot of feedback on the way > users wanted to use the API to realize applications. I incorporated all of > it, > and in this "release" I broadened the exposure per recommendations received > from > l-a-k. > This is precisely the problem. Stuff that gets "reviewed" on linux-arm-kernel gets reviewed for ARM only. There has been way too much crap that has been pushed into the kernel under the guise of being generic and "reviewed" that has broken _every_ architecture _except_ ARM. If you want to refute this, go look at the recent fiasco with musb, which still hasn't been solved properly, primarily because the ARM people couldn't be bothered using grep. This crap happens all the time, because stuff is reviewed and merged in private, and the only time anyone else notices is when their platform suddenly stops building. Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. > So, you're saying the same thing as me, basically. But leaving out the lists > with very high ratios of device-specific domain knowledge, which is important > for the backend parts of what I'm proposing. Blackfin's PWM-capable > peripherals > work differently from those commonly found in ARM and PPC, for example. I > haven't run anything by the MIPS or AVR guys, but I'm guessing they would have > something to add, too. > > I'm beginning to appreciate what everyone must have had to deal with for > GPIO. :) > The GPIO mess was broken in different ways, which we're still trying to fix today. The GPIO discussion did happen out on public lists though, so all of the discussion on that was visible, even if the end result left something to be desired. If you're trying to pitch a generic API and doing your review on a private list, you've already lost. If you're talking about things that only effect arch/arm, feel free to do whatever you want. As soon as you step outside of that structure, you have to follow common convention, or you risk breaking things all over the place. I can't remember the last time I saw a "generic" API reviewed on linux-arm-kernel that didn't end up breaking every other architecture in existence. This is true for drivers, also. Better yet, don't bother dropping the ARM depedency until you've posted to a public list. Some of us are pretty damn tired of cleaning up after the ARM people. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: > Paul Mundt wrote: > > This is likely because some of those lists are subscribers only, so cross > > posting is poor form. It makes sense to keep the discussion in one place, > > and to send notification messages with a pointer to the list archives to > > the other lists so folks can jump in if they really care. Splitting it > > out doesn't help matters in the least, but unfortunately this is what > > seems to happen the most when subscribers only lists are involved. > > Alright, then maybe I can do this when I post the "final" changeset for > review: > cross-post to lkml and linux-embedded, and then post one short note on l-a-k, > linuxppc-dev and elsewhere that refers those interested to the actual content. > I can live with that. > linux-arm-kernel is the only one that is subscribers only out of that list, according to MAINTAINERS. If rmk wants to mandate a broken policy, that's perfectly fine, just don't expect the rest of the kernel community to tolerate it. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 11:00:09AM +0200, Geert Uytterhoeven wrote: > On Thu, 9 Oct 2008, Bill Gatliff wrote: > > Benjamin Herrenschmidt wrote: > > > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: > > >> This series proposes a "generic PWM" driver API. > > >> > > >> This proposed API is motivated by the author's need to support > > >> pluggable devices; a secondary objective is to consolidate the > > >> existing PWM implementations behind an agreeable, consistent, > > >> redundancy-reducing interface. > > > > > > .../... > > > > > > You should send your patches to the main linux kernel list ! > > > > Perhaps. But it seemed more relevant to this crowd, and the linux-embedded > > crowd, and the linux-arm-kernel crowd. > > Were did you actually sent them to? Apparently you sent them to each mailing > list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). > > Hence different people may give the same comments without knowing about each > other, and you may have to explain everything multiple times. > > I would go for lkml and linux-embedded, _together_. > This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Wed, Aug 27, 2008 at 05:46:05PM -0700, David Miller wrote: > From: Paul Mundt <[EMAIL PROTECTED]> > Date: Thu, 28 Aug 2008 09:32:13 +0900 > > > On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote: > > > CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if > > > wanted with an arbitrary limit. > > > > In some cases, yes. In the CONFIG_DEBUG_STACKOVERFLOW case the check is > > only performed from do_IRQ(), which is sporadic at best, especially on > > tickless. While it catches some things, it's not a complete solution in > > and of iteslf. > > BTW, on sparc64 we have a stack overflow checker that runs via > the profiling _mcount hook. So every function call we check > if the stack is getting overused. > > If so, we jump onto a special static debugging stack and print > the stack overflow message. > > And yes it works with IRQ stacks which is all that sparc64 uses > nowadays. > > Perhaps this is useful enough to make generic. Thanks for the pointer, I'll take a look at it! -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote: > On Thu, Aug 28, 2008 at 01:00:52AM +0900, Paul Mundt wrote: > > On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote: > > In addition to that, debugging the runaway stack users on 4k tends to be > > easier anyways since you end up blowing the stack a lot sooner. On sh > > we've had pretty good luck with it, though most of our users are using > > fairly deterministic workloads and continually profiling the footprint. > > Anything that runs away or uses an insane amount of stack space needs to > > be fixed well before that anyways, so catching it sooner is always > > preferable. I imagine the same case is true for m68knommu (even sans IRQ > > stacks). > > CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if > wanted with an arbitrary limit. > In some cases, yes. In the CONFIG_DEBUG_STACKOVERFLOW case the check is only performed from do_IRQ(), which is sporadic at best, especially on tickless. While it catches some things, it's not a complete solution in and of iteslf. In addition to this, there are even fewer platforms that support it than there are platforms that do 4k stacks. At first glance, it looks like it's only m32r, powerpc, sh, x86, and xtensa. Others support the Kconfig option, but don't seem to realize that it's not an option that the kernel does anything with by itself, and so don't actually do anything (ie, FRV). > > Things might be more sensitive on x86, but it's certainly not something > > that's a huge problem for the various embedded platforms to wire up, > > whether they want to go the IRQ stack route or not. > > How many platforms use 4kB stacks on sh? > > Only 1 out of 34 defconfigs uses it. > The defconfigs tend to enable as much random stuff as people are interested in for development and testing purposes. Most of these end up being reference boards and are the basis for products, rather than shipping products themselves. In the latter case, everything is gradually tightened down, and 4k stack utilization in that case is the norm, rather than the exception. > > In any event, lack of support for something on embedded architectures in > > the kernel is more often due to apathy/utter indifference on the part of > > the architecture maintainer rather than being indicative of any intrinsic > > difficulty in supporting the thing in question. Most new "features" on the > > lesser maintained architectures tend to end up there either out of peer > > pressure or copying-and-pasting accidents rather than any sort of design. > > ;-) > > arm or powerpc aren't exactly lesser maintained architectures. > Indeed, which is why I find it bizarre that you would even bother applying what was said to those platforms. Specifically I was referring to the embedded platforms that don't do 4k stacks today. The fact they don't support them today has much less to do with 4k being an unattainable limit as it does with people simply not bothering to implement it on their platform. > IMHO there seems to currently be a mismatch between it's maintainance > cost and the actual number of users. That's in my opinion the main > problem with it, no matter in which direction it gets resolved. > Perhaps that's true on x86, but in general I take issue with that. On sh we've had to do very little maintenance for it and most shipping products are using it today (at least on MMU-Linux, we don't bother with it on nommu). Most of the problems we ran in to with 4k stacks tended to be stuff that we wanted to fix for 8k anyways. I suspect that this case is true for the other embedded platforms also. Note that on sh we also conditionalize IRQ stacks separately, so while they are often used together, it's possible to use 4k stacks without resorting to IRQ stacks (as m68knommu also seems to do). -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote: > On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote: > > On Wed, 27 Aug 2008, Adrian Bunk wrote: > > > > > > When did we get callpaths like like nfs+xfs+md+scsi reliably > > > working with 4kB stacks on x86-32? > > > > XFS may never have been usable, but the rest, sure. > > > > And you seem to be making this whole argument an excuse to SUCK, adn an > > excuse to let gcc crap even more on our stack space. > > > > Why? > > > > Why aren't you saying that we should be able to do better? Instead, you > > seem to asking us to do even worse than we do now? > > My main point is: > - getting 4kB stacks working reliably is a hard task > - having an eye on gcc increasing the stack usage, and fixing it if > required, is relatively easy > > If we should be able to do better at getting (and keeping) 4kB stacks > working, then coping with possible inlining problems caused by gcc > should not be a big problem for us. > Out of the architectures you've mentioned for 4k stacks, they also tend to do IRQ stacks, which is something you seem to have overlooked. In addition to that, debugging the runaway stack users on 4k tends to be easier anyways since you end up blowing the stack a lot sooner. On sh we've had pretty good luck with it, though most of our users are using fairly deterministic workloads and continually profiling the footprint. Anything that runs away or uses an insane amount of stack space needs to be fixed well before that anyways, so catching it sooner is always preferable. I imagine the same case is true for m68knommu (even sans IRQ stacks). Things might be more sensitive on x86, but it's certainly not something that's a huge problem for the various embedded platforms to wire up, whether they want to go the IRQ stack route or not. In any event, lack of support for something on embedded architectures in the kernel is more often due to apathy/utter indifference on the part of the architecture maintainer rather than being indicative of any intrinsic difficulty in supporting the thing in question. Most new "features" on the lesser maintained architectures tend to end up there either out of peer pressure or copying-and-pasting accidents rather than any sort of design. ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Remove more code when IP_MULTICAST=n
On Mon, Aug 25, 2008 at 08:48:25AM +0200, Thomas Petazzoni wrote: > Le Tue, 19 Aug 2008 16:18:38 +0200 (CEST), > Geert Uytterhoeven <[EMAIL PROTECTED]> a ??crit : > > > On Tue, 19 Aug 2008, Thomas Petazzoni wrote: > > > [RFC] Remove more code when IP_MULTICAST=n > > > > Probably you wanted to cc [EMAIL PROTECTED] > > Not necessarly at the beginning: I first wanted to get the feedback of > embedded-concerned developers, who might have a better understanding > than me of the networking stack. Last time I submitted a size-reduction > patch to Dave Miller concerning IGMP, the answer was: > > ?? > I'm not applying this. > > This removes core parts of the BSD socket API from applications. > Like TCP and UDP, multicast capabilities are something applications > can always depend upon being available. > > If you want a broken networking implementation, you have the source > code, so you can do it in your own tree. > ?? > > So, I'd prefer to send a good patch from the beginning. > Out of that bit of criticism, it's the validity of the approach in particular that's being called in to question, rather than the patch itself. How to clean up the patch itself is irrelevant if the idea itself is being shot down by the folks that will merge it. This is something that needs to be resolved first, and lists outside of the scope of netdev are really the wrong place to do this. This is generally the way a lot of the size reduction work seems to be going these days. Now that most of the low-hanging fruit is out of the way, it's mostly down to micro-optimizations aimed at things perceived to be core functionality by others. Expect to continue running in to these sorts of problems if you choose to continue down this path. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Adding a new platform
On Tue, Aug 19, 2008 at 08:57:59PM -0700, vb wrote: > On Tue, Aug 19, 2008 at 8:19 PM, Paul Gortmaker > <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 19, 2008 at 2:01 PM, David VomLehn <[EMAIL PROTECTED]> wrote: > >> I'm working to educate our management on the need to get our platform in > >> the > >> kernel mainline. I expect I will be asked to tell them how much work this > >> is. What do we need to do to add a new MIPS platform? > > > > Based on the phrase "educate our management" -- I would strongly suggest > > you > > have a look at Jonathan Corbet's document that describes the process and the > > eventual value-add of having things in-kernel -- with an audience of > > non-kernel > > hackers in mind. I think this will really assist you in your efforts, > > and I'm glad that > > Jonathan put the time into this that he did. > > > > His original post can be viewed here: > > > > http://lkml.org/lkml/2008/7/29/363 > > > > or here: > > > > http://lwn.net/Articles/291967/ > > > > This indeed is a very interesting document. I can hardly agree with > the below point, however: > > +- While kernel developers strive to maintain a stable interface to user > + space, the internal kernel API is in constant flux. The lack of a stable > + internal interface is a deliberate design decision; it allows fundamental > + improvements to be made at any time and results in higher-quality code. > + But one result of that policy is that any out-of-tree code requires > + constant upkeep if it is to work with new kernels. Maintaining > + out-of-tree code requires significant amounts of work just to keep that > + code working. > > so, say a developer submits a proprietary driver and it gets accepted. This doesn't make any sense to begin with. It's not possible to merge a proprietary driver in to the kernel. If you're talking about a GPLed driver, then the word proprietary here is meaningless (ie, whether hardware is widely available or not is not a concern as long as someone is actively looking after the code). On the other hand, if you are talking about an out-of-tree driver, then the maintenance burden is purely on whoever is maintaining that. > Then some internal kernel interface gets changed. Who now has to > modify and retest the driver? Is it the person who introduces the > change (how can he even do this, as he does not have the proprietary > hardware available)? Or is this the original submitter - then where is > the benefit of saving on upkeep? > In the general case, interface changes are done carefully, and in-tree users are converted over as to minimize breakage. Obviously whoever is making the change is not going to be able to test each driver, so it usually comes down to common sense. If there's something that's potentially problematic for a given driver, then testing is solicited from those that have a vested interest in the continued functionality of said driver. Likewise, if the change goes in and breaks things, that's a regression, and is usually reverted or quickly fixed once it's been identified. People that habitually cause regressions will suddenly find it much more difficult to get anything applied to the kernel, it's fairly self-regulating. People don't inherently go out of their way to break others code, but it certainly does happen. The main thing is that we have a pretty good process in place to handle those sorts of problems as they come up, so there's generally no reason _not_ to keep things changing. On the embedded side there is obviously the issue that some people will only test things once or twice a year, but at that level of active involvement, they may as well just do all of their things out-of-tree instead. > This constant change of the kernel innards is hardly a good selling > point, would you agree? > No, but there are others that might. Have you considered BSD? -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote: > Guys: > > > If you opt to cross-compile, having to deal with those > > sorts of things is the price you pay. > > > If the build system derives from autoconf, then a hacked-up config.cache (or > equivalent command-line args) often solves problems for me. Just give the > cache > the answers that it would otherwise have to get by running code on the target > machine. > > That's how emdebian is doing a bunch of their stuff, and I have to admit that > it > works pretty darned well. It's also handy for configuration management, since > the cache file itself is plaintext and therefore svn/git/bzr/cvs/...-friendly. > Yes, that's the easy case. It's things like perl that are the corner cases, and my objection comes from the fact that people think we ought to not have the kernel depend on perl rather than just fixing the package itself. Autoconf/libtool damage is an entirely different problem :-) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 04:50:31PM +0100, David Woodhouse wrote: > On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote: > > Rob Landley wrote: > > > However, having one or more full-time engineers devoted to debugging > > > cross-compile issues is quite a high price to pay too. Moore's law > > > really > > > doesn't help that one. > > > > > > I'm not saying either solution is perfect, I'm just saying the "build > > > under > > > emulation" approach is a viable alternative that gets more attractive as > > > time > > > passes, both because of ongoing development on emulators and because of > > > Moore's law on the hardware. > > > > I agree with much that you have said, Rob, and I understand the argument > > for getting the most gain from the least resources, but I have a > > philosophical > > problem with working around the cross-compilation problems instead of fixing > > them in the upstream packages (or in the autoconf system itself). > > > > Once someone fixes the cross-compilation issues for a package, they usually > > stay fixed, if the fixes are mainlined. > > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do > the wrong thing, and people will often introduce new problems. > > If we just made people write portable code and proper Makefiles, it > would be less of an issue :) > The other issue is that people that are working in this space tend to do very little beyond solving their immediate troubles. Since perl was mentioned, it also makes a good example. Embedded distros have been cross-compiling perl for pretty much the last decade, yet even today people are having the exact same issues and acting as this is some sort of surprise that needs to be worked arond, rather than treating it as a solved problem. If you opt to cross-compile, having to deal with those sorts of things is the price you pay. Holding the kernel hostage to this kind of brain-damage is simply beyond ridiculous. There are a lot of things outside of the kernel that have a dependency on perl too, how much time do people want to spend trying to fix the build system to match their environment before they realize their environment needs to scale to match the build environment that everyone else is already using? Building under qemu in a "native" environment is one way to work around this problem, and a lot of companies have opted for that approach rather than trying to fix the problematic packages. If you aren't building natively, your options are effectively limited by convention. You can either try to fix the packages in question, convince the package developers to rip out the parts that cause trouble for your environment, fix your own build environment to meet the needs of the packages, or whine about it on a mailing list. Empirically we already know which one of those options is going to win out. ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Tue, Jun 10, 2008 at 12:50:34PM +0200, Sam Ravnborg wrote: > > > > When did this policy change, so that it's now acceptable to depend on > > Perl, which is roughly equivalent as a tool dependency? > > We have perl as a mandatory part of the kernel build in several places > for various architectures. > And I do not recall anyone submitting a bug that they could not build > a kernel due to the perl dependency. > But I am obviously well aware of that we use it for the time stuff. > And plenty of places in scripts/ have dependencies on either perl or python already (and have for some time). Both are pretty ubiquitous these days, whether people like it or not. There's not much point in trying to keep the build limping along for people who don't want to set up these tools on their platforms, since they're going to lose out on half of the functionality anyways (checkstack, bloat-o-meter, etc.). Building natively is a good stress tester, and does find a lot of bugs. For that same reason, if you can build the kernel, you can build python and perl natively on your platform, too. Some of us have already been doing this for ages and have no idea what the fuss is about. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Tue, Jun 10, 2008 at 01:14:36PM +1000, Ben Nizette wrote: > On Mon, 2008-06-09 at 18:37 -0700, Tim Bird wrote: > > Rob Landley wrote: > > > On Friday 06 June 2008 18:47:47 Tim Bird wrote: > > >> At a minimum, it would be nice to have a few nice examples > > >> of really, really small configs for things like qemus for different > > >> architectures (just to give embedded developers who are working > > >> on size a starting point). > > > > > > That's more or less what I'm trying to do with my Firmware Linux project: > > > creating cross compilers and minimal native build environments for every > > > qemu > > > target. > > > > Any chance of getting your minimal configs from Firmware Linux mainlined? > > allnoconfig? ;-) > It's a bit counter-intuitive, given the inverted logic employed by many Kconfig options (enable vs disable and so on), default choices, select abuse, etc. If your platform happens to select EMBEDDED it's a pretty close approximation, though. > > Does anyone else think this would be valuable? If not in mainline, it > > would be nice to collect them somewhere, to compare what options different > > developers decide turn on or off. > > Seriously though I maintain a bunch of AVR32 minimal configs. I keep > them as a smallest-working-config baseline to build on; I'm sure others > would get value from having easy access to that kind of thing. > > IMO It'd be nice to wire them to an automagic bloat-o-meter as well, but > I suspect no-one would really take notice anyway. > Most people are not opposed to taking additional defconfigs if there's someone intends to use them and generally look after them. Many configs are already included in linux-next and similar for nightly builds, but that's more about making sure things keep working rather than size measurements. On the other hand, it would be useful to extend that sort of infrastructure to account for size changes, also, and there's certainly no reason why minimal configs can't be rolled in, too. For testing things like allmodconfig/allyesconfig and especially randconfigs tend to be the most useful, but it's fairly difficult to extract meaningful size statistics out of any of those. Likewise, a minimal config tends to be pointless to the extent that it's not actually useful for anything. Observing the growth in size on configurations that people are using in the real world is far more useful. Measuring arbitrary growth in a configuration that's not even usable isn't really much of an indicator of anything, except that someone might have too much free time on their hands. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console - Add configurable support for console charset translation
On Wed, Jun 04, 2008 at 12:36:11PM -0500, Rob Landley wrote: > Actually if you ever need to diagnose early boot stuff on _any_ platform, you > do need a console. But it can be serial or netconsole, as long as that > works... > Except for the minor fact that most early boot debugging happens long before the console subsystem is even available.. At the risk of perpetuating the stupidity of this thread.. If you ship a device to a customer expecting them to debug it for you, you are likewise not likely to be very commercially successful, either. Devices are not shipping with consoles, period. If you disagree with this, you've obviously never shipped a device. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console - Add configurable support for console charset translation
On Tue, Jun 03, 2008 at 03:37:23PM -0700, H. Peter Anvin wrote: > Rob Landley wrote: > >>Actually, lots have frame buffers these days. > > > >Cell phones, for instance. > > Sure, but do you want to use them as consoles? > Unless your name is Pavel, no one actually wants a console on their phone. So no, just framebuffers, as is to be expected :-) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
