LinuxLists.cc - [PATCH] BLOCK: Make it possible to disable the block layer

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 14:00 +0100, David Howells wrote:
> Make it possible to disable the block layer. Not all embedded devices require
> it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
> the block layer to be present.
>
> This patch does the following:
>
> (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
> support.

Excellent -- I've been meaning to do this (and occasionally hacking on
it half-heartedly before getting distracted by something else shiny) for
a _long_ time.

It looks good in general.

> (*) The contents of a number of filesystem- and blockdev-specific header files
> are now contingent on their own configuration options. This includes:
> Ext3/JBD, RAID, MSDOS and ReiserFS.

Why? Those header files shouldn't be included from anywhere _but_ the
code in question, and in fact should probably be just moved into fs/foo
instead of living in include/linux/foo_fs.h.

And please, _never_ make anything dependent on CONFIG_foo_MODULE.

--
dwmw2

2006-08-24 13:34:43

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

David Woodhouse <[email protected]> wrote:

> > (*) The contents of a number of filesystem- and blockdev-specific header
> > files are now contingent on their own configuration options. This
> > includes: Ext3/JBD, RAID, MSDOS and ReiserFS.
>
> Why? Those header files shouldn't be included from anywhere _but_ the
> code in question,

Go and look at fs/compat_ioctl.c.

> and in fact should probably be just moved into fs/foo instead of living in
> include/linux/foo_fs.h.

Definitely. Patches please:-)

> And please, _never_ make anything dependent on CONFIG_foo_MODULE.

Ah, but... The core kernel makes use of the certain header files, even when
their actual intended target is compiled as a module. If I just use
"CONFIG_foo" only, then the module won't compile as a module.

David

2006-08-24 13:41:05

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 14:34 +0100, David Howells wrote:
> Ah, but... The core kernel makes use of the certain header files, even when
> their actual intended target is compiled as a module. If I just use
> "CONFIG_foo" only, then the module won't compile as a module.

So don't put it in the header file itself. Just do

#ifdef CONFIG_foo
#include <linux/foo.h>
#endif

Better still, avoid the need for the external code to poke at fs-private
header files at all.

--
dwmw2

2006-08-24 13:48:07

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 02:00:42PM +0100, David Howells wrote:
>
> Make it possible to disable the block layer. Not all embedded devices require
> it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
> the block layer to be present.
>
> This patch does the following:
>
> (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
> support.
>
> (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
> an item that uses the block layer. This includes:
>
> (*) Block I/O tracing.
>
> (*) Disk partition code.
>
> (*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
>
> (*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
> block layer to do scheduling.
>
> (*) Various block-based device drivers, such as IDE, the old CDROM
> drivers and USB storage.
>
> (*) MTD blockdev handling and FTL.
>
> (*) JFFS - which uses set_bdev_super(), something it could avoid doing by
> taking a leaf out of JFFS2's book.

So far a very good idea and I very much welcome this - it's been long overdue.

> (*) Made most of the contents of linux/blkdev.h, linux/buffer_head.h and
> linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
> however, still used in places.
>
> (*) The contents of linux/blktrace_api.h are contingent now on CONFIG_BLOCK in
> addition to CONFIG_BLK_DEV_IO_TRACE, possibly unnecessarily.
>
> (*) Also contingent are the contents of linux/mpage.h, linux/genhd.h and parts
> of linux/fs.h.
>
> (*) The contents of a number of filesystem- and blockdev-specific header files
> are now contingent on their own configuration options. This includes:
> Ext3/JBD, RAID, MSDOS and ReiserFS.
>

Now this is quite bad - we avoid ifdefs where we can. People will notice
their module won't link if they don't get the dependencies right.

Note that in the case of linux/blktrace_api.h it's really bad as that
header contains a userspace ABI.

> (*) Moved some stuff out of fs/buffer.c:
>
> (*) The file sync and general sync stuff moved to fs/sync.c.
>
> (*) The superblock sync stuff moved to fs/super.c.
>
> (*) do_invalidatepage() moved to mm/truncate.c.
>
> (*) try_to_release_page() moved to mm/filemap.c.

This is very nice, but please submit it as a separate patch, before the
actual CONFIG_BLOCK introduction.

Also I'm not sure the try_to_release_page variant is actually right as
we still have that horrible default of try_to_free_buffers() if there's
no releasepage method.

> (*) Moved some stuff between header files:
>
> (*) declarations for do_invalidatepage() and try_to_release_page() moved
> to linux/mm.h.
>
> (*) __set_page_dirty_buffers() moved to linux/buffer_head.h.

makes sense I think - but this also belongs into the above preparation
patch.

>
> (*) The duplicate declaration of exit_io_context() has been removed from
> linux/sched.h.

ACK, tiny patch of it's own.

>
> (*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
> is not enabled.
>
> (*) fallback_migrate_page() uses PagePrivate() instead of page_has_buffers().

tiny fix on it's own - it's actually a separate buf

>
> (*) The bounce buffer stuff moved from mm/highmem.c to mm/bounce.c, which is
> contingent on CONFIG_BLOCK.

Nice, but please make this a separate patch.

> (*) The AFS filesystem specifies block_sync_page() as its sync_page address
> op, which needs to be checked, and so is commented out.

separate patch, please.

> (*) The bdev_cache_init() extern declaration was moved from fs/dcache.c to
> linux/blkdev.h.

dito.

>
> (*) The blockdev_superblock extern declaration was moved from
> fs/fs-writeback.c to linux/blkdev.h.

separate patch

> (*) fs/fs-writeback.c no longer depends on blockdev_superblock to be present.

please do this without all the ifdefs in .c files.

> (*) fs/no-block.c was incorporated to hold a couple of things for when
> CONFIG_BLOCK was not set:
>
> (*) A version generic_writepages(), which is used by NFS. This is derived
> from mpage_writepages() with all the BIO references removed.

if we already have a duplicate copy of it we should use it all the time.
Maybe there's even a way to avoid this. please submit it as a broken
out patch so smart people like akpm can help solving this problem without
steeping through this huge patch :)

> (*) In init/do_mounts.c, no reference is made to the blockdev routines if
> CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.

please split that code out into a do_mounts_block.c like the other special
case root mount code.

> (*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
> error ENOSYS if so).

please use cond_syscall for them.

> (*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
> CONFIG_BLOCK is not set, since they can't then happen.

I though we agreed to kill the seclvl crap? We should kill those broken
LSM callouts aswell then.

2006-08-24 13:54:14

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

David Woodhouse <[email protected]> wrote:

> So don't put it in the header file itself. Just do
>
> #ifdef CONFIG_foo
> #include <linux/foo.h>
> #endif

That still doesn't work, but for a different reason.

> Better still, avoid the need for the external code to poke at fs-private
> header files at all.

Yeah.

David

2006-08-24 14:42:56

by Nick Piggin

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

David Howells wrote:
[...]

Cool. How much RAM does it save?

> --- /dev/null
> +++ b/fs/no-block.c
> @@ -0,0 +1,160 @@
> +/* no-block.c: implementation of routines required for non-BLOCK configuration
> + *
> + * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells ([email protected])
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include <linux/mpage.h>
> +#include <linux/writeback.h>
> +#include <linux/backing-dev.h>
> +#include <linux/pagevec.h>
> +#include <linux/pagemap.h>
> +
> +/**
> + * generic_writepages - walk the list of dirty pages of the given
> + * address space and writepage() all of them.
> + *
> + * @mapping: address space structure to write
> + * @wbc: subtract the number of written pages from *@wbc->nr_to_write
> + *
> + * This is a library function, which implements the writepages()
> + * address_space_operation.
> + *
> + * If a page is already under I/O, generic_writepages() skips it, even
> + * if it's dirty. This is desirable behaviour for memory-cleaning writeback,
> + * but it is INCORRECT for data-integrity system calls such as fsync(). fsync()
> + * and msync() need to guarantee that all the data which was dirty at the time
> + * the call was made get new I/O started against them. If wbc->sync_mode is
> + * WB_SYNC_ALL then we were called for data integrity and we must wait for
> + * existing IO to complete.
> + */
> +int generic_writepages(struct address_space *mapping,
> + struct writeback_control *wbc)

This isn't the right thing to do. Even just ifdefing the bio stuff would
seem better... but you didn't seem shy about adding ifdefs in other code,
so what is the problem with doing it here?

You also forgot to put akpm in your copyright notice, fwiw.

> +{
> + struct backing_dev_info *bdi = mapping->backing_dev_info;
> + int ret = 0;
> + int done = 0;
> + int (*writepage)(struct page *page, struct writeback_control *wbc);
> + struct pagevec pvec;
> + int nr_pages;
> g+ pgoff_t index;
> + pgoff_t end; /* Inclusive */
> + int scanned = 0;
> + int range_whole = 0;
> +
> + if (wbc->nonblocking && bdi_write_congested(bdi)) {
> + wbc->encountered_congestion = 1;
> + return 0;
> + }
> +
> + writepage = mapping->a_ops->writepage;
> +
> + /* deal with chardevs and other special file */
> + if (!writepage)
> + return 0;
> +
> + pagevec_init(&pvec, 0);
> + if (wbc->range_cyclic) {
> + index = mapping->writeback_index; /* Start from prev offset */
> + end = -1;
> + } else {
> + index = wbc->range_start >> PAGE_CACHE_SHIFT;
> + end = wbc->range_end >> PAGE_CACHE_SHIFT;
> + if (wbc->range_start == 0 && wbc->range_end == LLONG_MAX)
> + range_whole = 1;
> + scanned = 1;
> + }
> +retry:
> + while (!done && (index <= end) &&
> + (nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
> + PAGECACHE_TAG_DIRTY,
> + min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1))) {
> + unsigned i;
> +
> + scanned = 1;
> + for (i = 0; i < nr_pages; i++) {
> + struct page *page = pvec.pages[i];
> +
> + /*
> + * At this point we hold neither mapping->tree_lock nor
> + * lock on the page itself: the page may be truncated or
> + * invalidated (changing page->mapping to NULL), or even
> + * swizzled back from swapper_space to tmpfs file
> + * mapping
> + */
> +
> + lock_page(page);
> +
> + if (unlikely(page->mapping != mapping)) {
> + unlock_page(page);
> + continue;
> + }
> +
> + if (!wbc->range_cyclic && page->index > end) {
> + done = 1;
> + unlock_page(page);
> + continue;
> + }
> +
> + if (wbc->sync_mode != WB_SYNC_NONE)
> + wait_on_page_writeback(page);
> +
> + if (PageWriteback(page) ||
> + !clear_page_dirty_for_io(page)) {
> + unlock_page(page);
> + continue;
> + }
> +
> + ret = (*writepage)(page, wbc);
> + if (ret) {
> + if (ret == -ENOSPC)
> + set_bit(AS_ENOSPC, &mapping->flags);
> + else
> + set_bit(AS_EIO, &mapping->flags);
> + }
> +
> + if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
> + unlock_page(page);
> + if (ret || (--(wbc->nr_to_write) <= 0))
> + done = 1;
> + if (wbc->nonblocking && bdi_write_congested(bdi)) {
> + wbc->encountered_congestion = 1;
> + done = 1;
> + }
> + }
> + pagevec_release(&pvec);
> + cond_resched();
> + }
> + if (!scanned && !done) {
> + /*
> + * We hit the last page and there is more work to be done: wrap
> + * back to the start of the file
> + */
> + scanned = 1;
> + index = 0;
> + goto retry;
> + }
> + if (wbc->range_cyclic || (range_whole && wbc->nr_to_write > 0))
> + mapping->writeback_index = index;
> + return ret;
> +}
> +
> +EXPORT_SYMBOL(generic_writepages);

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

2006-08-24 15:29:40

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 02:00:42PM +0100, David Howells wrote:
>...
> +config BLOCK
> + bool "Enable the block layer"

bool "Enable the block layer" depends on EMBEDDED

> + default y
> + help
>...
> --- a/drivers/ieee1394/Kconfig
> +++ b/drivers/ieee1394/Kconfig
> @@ -122,7 +122,7 @@ config IEEE1394_VIDEO1394
>
> config IEEE1394_SBP2
> tristate "SBP-2 support (Harddisks etc.)"
> - depends on IEEE1394 && SCSI && (PCI || BROKEN)
> + depends on IEEE1394 && BLOCK && SCSI && (PCI || BROKEN)
> help
> This option enables you to use SBP-2 devices connected to your IEEE
> 1394 bus. SBP-2 devices include harddrives and DVD devices.
> diff --git a/drivers/infiniband/ulp/iser/Kconfig b/drivers/infiniband/ulp/iser/Kconfig
> index fead87d..f945953 100644
> --- a/drivers/infiniband/ulp/iser/Kconfig
> +++ b/drivers/infiniband/ulp/iser/Kconfig
> @@ -1,6 +1,6 @@
> config INFINIBAND_ISER
> tristate "ISCSI RDMA Protocol"
> - depends on INFINIBAND && SCSI
> + depends on INFINIBAND && BLOCK && SCSI
> select SCSI_ISCSI_ATTRS
> ---help---
> Support for the ISCSI RDMA Protocol over InfiniBand. This
> diff --git a/drivers/infiniband/ulp/srp/Kconfig b/drivers/infiniband/ulp/srp/Kconfig
> index 8fe3be4..63d7d5a 100644
> --- a/drivers/infiniband/ulp/srp/Kconfig
> +++ b/drivers/infiniband/ulp/srp/Kconfig
> @@ -1,6 +1,6 @@
> config INFINIBAND_SRP
> tristate "InfiniBand SCSI RDMA Protocol"
> - depends on INFINIBAND && SCSI
> + depends on INFINIBAND && BLOCK && SCSI
> ---help---
> Support for the SCSI RDMA Protocol over InfiniBand. This
> allows you to access storage devices that speak SRP over
>...
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
>...
> @@ -43,7 +45,7 @@ comment "SCSI support type (disk, tape,
>
> config BLK_DEV_SD
> tristate "SCSI disk support"
> - depends on SCSI
> + depends on SCSI && BLOCK
> ---help---
> If you want to use SCSI hard disks, Fibre Channel disks,
> USB storage or the SCSI or parallel port version of
> @@ -98,7 +100,7 @@ config CHR_DEV_OSST
>
> config BLK_DEV_SR
> tristate "SCSI CDROM support"
> - depends on SCSI
> + depends on SCSI && BLOCK
> ---help---
> If you want to use a SCSI or FireWire CD-ROM under Linux,
> say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
> @@ -473,7 +475,7 @@ source "drivers/scsi/megaraid/Kconfig.me
>
> config SCSI_SATA
> tristate "Serial ATA (SATA) support"
> - depends on SCSI
> + depends on SCSI && BLOCK
> help
> This driver family supports Serial ATA host controllers
> and devices.
>...

Unless the dependency of SCSI on BLOCK you introduce should go away
these are not required.

cu
Adrian

--

Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).

There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli

2006-08-24 15:45:17

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
> bool "Enable the block layer" depends on EMBEDDED

Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
sole purpose is to pander to Aunt Tillie.

--
dwmw2

2006-08-24 15:58:17

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 04:44:34PM +0100, David Woodhouse wrote:
> On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
> > bool "Enable the block layer" depends on EMBEDDED
>
> Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
> sole purpose is to pander to Aunt Tillie.

It's not for Aunt Tillie.
It's for an average system administrator who compiles his own kernel.

CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
possible, and I really know what I'm doing" people.

There's no reason for getting linux-kernel swamped with
"my kernel doesn't boot" messages by people who accidentally disabled
this option.

> dwmw2

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-24 16:00:27

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 17:58 +0200, Adrian Bunk wrote:
> There's no reason for getting linux-kernel swamped with
> "my kernel doesn't boot" messages by people who accidentally disabled
> this option.

By that logic, you should make it necessary to set CONFIG_EMBEDDED
before you can set CONFIG_EXT3 != Y or CONFIG_IDE != Y too.

However you dress it up, it's pandering to someone who either lacks the
wit, or just can't be bothered, to _look_ at what they're doing when
they configure their kernel. And it's a bad thing.

--
dwmw2

2006-08-24 16:09:29

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 05:00:16PM +0100, David Woodhouse wrote:
> On Thu, 2006-08-24 at 17:58 +0200, Adrian Bunk wrote:
> > There's no reason for getting linux-kernel swamped with
> > "my kernel doesn't boot" messages by people who accidentally disabled
> > this option.
>
> By that logic, you should make it necessary to set CONFIG_EMBEDDED
> before you can set CONFIG_EXT3 != Y or CONFIG_IDE != Y too.

That's the difference between Aunt Tillie and a system administrator:
A system administrator knows which filesystems he wants to use.

> However you dress it up, it's pandering to someone who either lacks the
> wit, or just can't be bothered, to _look_ at what they're doing when
> they configure their kernel. And it's a bad thing.

We already have too many user visible options and too many ways for
people to create non-working kernels.

There's no need for additional traps.

> dwmw2

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-24 16:26:45

by Stefan Richter

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

David Howells wrote:
...
> (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
> an item that uses the block layer. This includes:
...
> (*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
> block layer to do scheduling.
>
> (*) Various block-based device drivers, such as IDE, the old CDROM
> drivers and USB storage.
...

Side note w/o consequence for your patch: usb-storage is not a
block-based device driver. It is a SCSI low-level provider which happens
to need symbols from the block layer to adjust parameters of the SCSI
request queue since there are no fitting abstractions supplied by the
SCSI mid-level.
--
Stefan Richter
-=====-=-==- =--- ==---
http://arcgraph.de/sr/

2006-08-24 16:43:50

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>> On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
>> > bool "Enable the block layer" depends on EMBEDDED
>>
>> Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
>> sole purpose is to pander to Aunt Tillie.
>
>It's not for Aunt Tillie.
>It's for an average system administrator who compiles his own kernel.
>
>CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
>possible, and I really know what I'm doing" people.

Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
CONFIG_EMBEDDED.

>There's no reason for getting linux-kernel swamped with
>"my kernel doesn't boot" messages by people who accidentally disabled
>this option.

Jan Engelhardt
--

2006-08-24 16:44:54

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 18:39 +0200, Jan Engelhardt wrote:
> Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
> CONFIG_EMBEDDED.

Let's just call it CONFIG_AUNT_TILLIE and have done with it.

--
dwmw2

2006-08-24 16:48:05

by Alexey Dobriyan

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 06:09:26PM +0200, Adrian Bunk wrote:
> On Thu, Aug 24, 2006 at 05:00:16PM +0100, David Woodhouse wrote:
> > On Thu, 2006-08-24 at 17:58 +0200, Adrian Bunk wrote:
> > > There's no reason for getting linux-kernel swamped with
> > > "my kernel doesn't boot" messages by people who accidentally disabled
> > > this option.
> >
> > By that logic, you should make it necessary to set CONFIG_EMBEDDED
> > before you can set CONFIG_EXT3 != Y or CONFIG_IDE != Y too.
>
> That's the difference between Aunt Tillie and a system administrator:
> A system administrator knows which filesystems he wants to use.
>
> > However you dress it up, it's pandering to someone who either lacks the
> > wit, or just can't be bothered, to _look_ at what they're doing when
> > they configure their kernel. And it's a bad thing.
>
> We already have too many user visible options

Examples please.

> and too many ways for people to create non-working kernels.
>
> There's no need for additional traps.

2006-08-24 16:48:24

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 06:39:14PM +0200, Jan Engelhardt wrote:
> >> On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
> >> > bool "Enable the block layer" depends on EMBEDDED
> >>
> >> Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
> >> sole purpose is to pander to Aunt Tillie.
> >
> >It's not for Aunt Tillie.
> >It's for an average system administrator who compiles his own kernel.
> >
> >CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
> >possible, and I really know what I'm doing" people.
>
> Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
> CONFIG_EMBEDDED.

It makes sense that there is one option only for additional space
savings.

But you are right, we need a second option for not space related expert
options.

I'll send a patch for this.

> Jan Engelhardt

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-24 17:07:13

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 08:47:52PM +0400, Alexey Dobriyan wrote:
> On Thu, Aug 24, 2006 at 06:09:26PM +0200, Adrian Bunk wrote:
> > On Thu, Aug 24, 2006 at 05:00:16PM +0100, David Woodhouse wrote:
> > > On Thu, 2006-08-24 at 17:58 +0200, Adrian Bunk wrote:
> > > > There's no reason for getting linux-kernel swamped with
> > > > "my kernel doesn't boot" messages by people who accidentally disabled
> > > > this option.
> > >
> > > By that logic, you should make it necessary to set CONFIG_EMBEDDED
> > > before you can set CONFIG_EXT3 != Y or CONFIG_IDE != Y too.
> >
> > That's the difference between Aunt Tillie and a system administrator:
> > A system administrator knows which filesystems he wants to use.
> >
> > > However you dress it up, it's pandering to someone who either lacks the
> > > wit, or just can't be bothered, to _look_ at what they're doing when
> > > they configure their kernel. And it's a bad thing.
> >
> > We already have too many user visible options
>
> Examples please.
>...

Do a "make menuconfig" and look at the number of options.

There's e.g. no reason to ask all users whether they want to compile all
I/O schedulers into their kernel.

To avoid misunderstandings:

I'm not talking about people subscribed to this list.

It's more about a system administrator who must for some reason (e.g.
hardware support or the requirement of some external patch) compile his
own kernel.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-24 17:16:35

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 19:07 +0200, Adrian Bunk wrote:
> Do a "make menuconfig" and look at the number of options.

Why would I do that? I haven't done that for _years_. I've just edited
the .config file, removed the line which turns some option on or off,
then run 'make oldconfig'. I get asked about the option in question, and
then if I've turned something on I get asked about other options which
depend on it and which are now possible but weren't before.

Increasingly, these days, that approach has been failing due to all this
Aunt Tillie crap. I tried turning off CONFIG_KALLSYMS the other day, but
it took me a while to work out how. And the increasing use of 'select'
is even worse.

> There's e.g. no reason to ask all users whether they want to compile all
> I/O schedulers into their kernel.
>
> To avoid misunderstandings:
>
> I'm not talking about people subscribed to this list.
>
> It's more about a system administrator who must for some reason (e.g.
> hardware support or the requirement of some external patch) compile his
> own kernel.

Why on earth would they create a config file from scratch instead of
using a defconfig or the config from their distribution and modifying it
so suit their needs?

For most things, they ought to be able to just build extra modules to
_match_ their distribution's kernel, without having to rebuild the
kernel itself. (Although people doing stupid things in the kernel like
#ifdef CONFIG_foo_MODULE tends to screw them sometimes -- I can't build
IPv6 for my Nokia 770 without replacing its kernel, for example).

People just don't have that much cause to create configs from scratch --
there's little benefit in pandering to those who are less able. Make the
_defaults_ sane, by all means -- but don't just start hiding options.

However you dress it up, it's still ESR's Aunt Tillie come to haunt us.
And it's a PITA.

--
dwmw2

2006-08-24 17:19:42

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

Adrian Bunk <[email protected]> wrote:

> CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
> possible, and I really know what I'm doing" people.

It's not a speed thing so much as a space thing.

David

2006-08-24 17:23:21

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 06:18:27PM +0100, David Howells wrote:
> Adrian Bunk <[email protected]> wrote:
>
> > CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
> > possible, and I really know what I'm doing" people.
>
> It's not a speed thing so much as a space thing.

Yes, sorry, I really wanted to write "small" instead of "fast".

> David

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-24 17:31:49

by Randy Dunlap

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 24 Aug 2006 18:16:03 +0100 David Woodhouse wrote:

> On Thu, 2006-08-24 at 19:07 +0200, Adrian Bunk wrote:
> > Do a "make menuconfig" and look at the number of options.
>
> Why would I do that? I haven't done that for _years_. I've just edited
> the .config file, removed the line which turns some option on or off,
> then run 'make oldconfig'. I get asked about the option in question, and
> then if I've turned something on I get asked about other options which
> depend on it and which are now possible but weren't before.

How do you do that if you have all of ISDN disabled and want/need
to enable one ISDN driver? or same problem for V4L(2)/dvb?
or several other subsystems? (e.g. sound)

> Increasingly, these days, that approach has been failing due to all this
> Aunt Tillie crap. I tried turning off CONFIG_KALLSYMS the other day, but
> it took me a while to work out how. And the increasing use of 'select'
> is even worse.
>
> > There's e.g. no reason to ask all users whether they want to compile all
> > I/O schedulers into their kernel.
> >
> > To avoid misunderstandings:
> >
> > I'm not talking about people subscribed to this list.
> >
> > It's more about a system administrator who must for some reason (e.g.
> > hardware support or the requirement of some external patch) compile his
> > own kernel.
>
> Why on earth would they create a config file from scratch instead of
> using a defconfig or the config from their distribution and modifying it
> so suit their needs?
>
> For most things, they ought to be able to just build extra modules to
> _match_ their distribution's kernel, without having to rebuild the
> kernel itself. (Although people doing stupid things in the kernel like
> #ifdef CONFIG_foo_MODULE tends to screw them sometimes -- I can't build
> IPv6 for my Nokia 770 without replacing its kernel, for example).
>
> People just don't have that much cause to create configs from scratch --
> there's little benefit in pandering to those who are less able. Make the
> _defaults_ sane, by all means -- but don't just start hiding options.
>
> However you dress it up, it's still ESR's Aunt Tillie come to haunt us.
> And it's a PITA.

---
~Randy

2006-08-24 17:49:18

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 2006-08-24 at 10:34 -0700, Randy.Dunlap wrote:
> How do you do that if you have all of ISDN disabled and want/need
> to enable one ISDN driver? or same problem for V4L(2)/dvb?
> or several other subsystems? (e.g. sound)

If you _ever_ catch me getting confused because I'm trying to build an
ISDN driver and I can't work out that in order to do this, I might need
to first enable CONFIG_ISDN, then I promise you I will change my name by
deed poll to 'Aunt Tillie'.

It isn't hard to find dependencies by looking in the Kconfig files, even
if they are slightly less blindingly obvious than that example. I think
'make xconfig' will even show you the dependencies these days. I
remember even in about 1996 the Nemesis folks had hacked the old tcl
xconfig script to show dependencies.

Finding the brain-damaged 'select' which is preventing me from turning a
given option _off_, however, is something I tend to find far more
difficult. The CONFIG_EMBEDDED crap took up a painful amount of my time
last week when it bit me too.

--
dwmw2

2006-08-24 17:55:32

by Sam Ravnborg

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006 at 06:48:44PM +0100, David Woodhouse wrote:
> Finding the brain-damaged 'select' which is preventing me from turning a
> given option _off_, however, is something I tend to find far more
> difficult. The CONFIG_EMBEDDED crap took up a painful amount of my time
> last week when it bit me too.

Here meuconfig can be a great help for you. Trying the help option
tells you a bit more about what needs to be done to disable
a given option.

Sam

2006-08-24 17:57:53

by Randy Dunlap

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, 24 Aug 2006 18:48:44 +0100 David Woodhouse wrote:

> On Thu, 2006-08-24 at 10:34 -0700, Randy.Dunlap wrote:
> > How do you do that if you have all of ISDN disabled and want/need
> > to enable one ISDN driver? or same problem for V4L(2)/dvb?
> > or several other subsystems? (e.g. sound)
>
> If you _ever_ catch me getting confused because I'm trying to build an
> ISDN driver and I can't work out that in order to do this, I might need
> to first enable CONFIG_ISDN, then I promise you I will change my name by
> deed poll to 'Aunt Tillie'.

I'd rather use menuconfig or xconfig for that instead of editing
.config and reading multiple Kconfig files.

But I'd still prefer to have an "Enable all of this subsystem options first"
switch like I suggested a few months ago. Makes it easier to view
and disable options.

> It isn't hard to find dependencies by looking in the Kconfig files, even
> if they are slightly less blindingly obvious than that example. I think
> 'make xconfig' will even show you the dependencies these days. I
> remember even in about 1996 the Nemesis folks had hacked the old tcl
> xconfig script to show dependencies.

menuconfig or xconfig will show dependencies now.

> Finding the brain-damaged 'select' which is preventing me from turning a
> given option _off_, however, is something I tend to find far more
> difficult. The CONFIG_EMBEDDED crap took up a painful amount of my time
> last week when it bit me too.

Ack.

---
~Randy

2006-08-24 18:39:52

by Matthias Schniedermeyer

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

Jan Engelhardt wrote:
>>>On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
>>>
>>>> bool "Enable the block layer" depends on EMBEDDED
>>>
>>>Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
>>>sole purpose is to pander to Aunt Tillie.
>>
>>It's not for Aunt Tillie.
>>It's for an average system administrator who compiles his own kernel.
>>
>>CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
>>possible, and I really know what I'm doing" people.
>
>
> Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
> CONFIG_EMBEDDED.

Or to quote the GUI-configuration of xine-ui

CONFIG_EXPERIENCE_LEVEL
With the options:
Beginner
Advanced
Expert
Master of the know universe

SCNR. ;-)

Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

2006-08-24 21:32:18

by Johannes Stezenbach

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24, 2006, Adrian Bunk wrote:
> On Thu, Aug 24, 2006 at 06:39:14PM +0200, Jan Engelhardt wrote:
> > >> On Thu, 2006-08-24 at 17:29 +0200, Adrian Bunk wrote:
> > >> > bool "Enable the block layer" depends on EMBEDDED
> > >>
> > >> Please. no. CONFIG_EMBEDDED was a bad idea in the first place -- its
> > >> sole purpose is to pander to Aunt Tillie.
> > >
> > >It's not for Aunt Tillie.
> > >It's for an average system administrator who compiles his own kernel.
> > >
> > >CONFIG_BLOCK=n will only be for the "the kernel must become as fast as
> > >possible, and I really know what I'm doing" people.
> >
> > Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
> > CONFIG_EMBEDDED.
>
> It makes sense that there is one option only for additional space
> savings.
>
> But you are right, we need a second option for not space related expert
> options.

I think the sole purpose of CONFIG_EMBEDDED is to reduce noise from
silly pseudo-bug reports. The rather uninteresting name helps.
If you have CONFIG_EXPERT, of course _everone_ will enable it,
shoot themselves in the foot and will be happy to inform you
about it, wasting their and _your_ time.

Johannes

2006-08-25 06:08:34

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>> Then that should be CONFIG_I_AM_AN_EXPERT (CONFIG_EXPERT), not
>> CONFIG_EMBEDDED.
>
>It makes sense that there is one option only for additional space
>savings.
>
>But you are right, we need a second option for not space related expert
>options.

The question is whether CONFIG_BLOCK is
- a space-saving option
- or an expert option
or both? Maybe one should only be able to disable it when both
CONFIG_EXPERT=y and CONFIG_EMBEDDED=y. What are you thinking?

Jan Engelhardt
--

2006-08-25 06:11:41

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>Or to quote the GUI-configuration of xine-ui
>
>CONFIG_EXPERIENCE_LEVEL
>With the options:
>Beginner
>Advanced
>Expert
>Master of the know universe
>
>SCNR. ;-)

I seem to like this idea. Although it somehow may contradict
defconfig. (If a Beginner user would just do what he was told to - make
defconfig/allmodconfig -- in the ideal case, he should get a usable
system.)

Jan Engelhardt
--

2006-08-25 06:13:10

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>
>There's e.g. no reason to ask all users whether they want to compile all
>I/O schedulers into their kernel.
>
The users that do not know how to handle it should not be compiling a
kernel. If in doubt, they should read the help texts and follow the "If
unsure" clause listed there.

Jan Engelhardt
--

2006-08-25 06:26:59

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>
>Increasingly, these days, that approach has been failing due to all this
>Aunt Tillie crap. I tried turning off CONFIG_KALLSYMS the other day, but
>it took me a while to work out how. And the increasing use of 'select'
>is even worse.

menuconfig could include a feature which lists a dependency tree on the
current option, that is, f.ex., hitting 'D' on CONFIG_INET_AH (IP: AH
transformation) could
give this screen:

--- Depends ---
[ ] Networking support
[ ] TCP/IP networking
--- Selects ---
[*] CONFIG_XFRM
[*] Cryptogrpahic API
--- HMAC support
<M> MD5 digest algorithm
<M> SHA1 digest algorithm
--- Selected by ---

And, now let's take a 'D' on CONFIG_CRYPTO_HMAC:

--- Depends ---
[*] Cryptographic API
--- Selects ---
--- Selected by ---
[*] Experimental
[*] Networking support
[*] TCP/IP Networking
[*] INET: AH transform
[*] INET: ESP transform
[*] INET6: AH transform
[*] INET6: ESP transform
[*] SCTP

So you can:
- enable any Depends to make CONFIG_INET_AH available
- see what it selects and cycle between <*> and <M> (if possible)
for Selected options
- deselect all the Selected Bys to be able to unselect CRYPTO_HMAC
itself[3]

[3] would be a tough thing because you can select with && and ||, in which
case it should simply list all the options specified in the Kconfig without
regard to && and || combinatinos.

Jan Engelhardt
--

2006-08-25 06:32:39

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

>
>Here meuconfig can be a great help for you. Trying the help option
>tells you a bit more about what needs to be done to disable
>a given option.

Some nitpick: when there are a lot of dependencies or a long select
or long selected by list, you need to scroll far to the right, and possibly
back left again. This takes time because the normal user set a keyboard
repeat rate at about 30. (Under X, I prefer 35, but that's unfortunately
not available on 80x25/console/tty1.)
These lines should be wrapped

Jan Engelhardt
--

2006-08-25 07:15:30

by Sam Ravnborg

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Fri, Aug 25, 2006 at 08:23:28AM +0200, Jan Engelhardt wrote:
> >
> >Here meuconfig can be a great help for you. Trying the help option
> >tells you a bit more about what needs to be done to disable
> >a given option.
>
> Some nitpick: when there are a lot of dependencies or a long select
> or long selected by list, you need to scroll far to the right, and possibly
> back left again. This takes time because the normal user set a keyboard
> repeat rate at about 30. (Under X, I prefer 35, but that's unfortunately
> not available on 80x25/console/tty1.)
> These lines should be wrapped

One day when I feel in the right mode I will try to cook up something
so you can get a menu where you can change the individual items referend for
a symbol.
This should allow you to say N to all selected symbols except the symbols
that is selected where you have to take one step deeper in the hirachy.

But there are more exiting project ahead than just this one so...

Sam

2006-08-25 10:37:56

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Fri, Aug 25, 2006 at 08:07:37AM +0200, Jan Engelhardt wrote:
> >
> >There's e.g. no reason to ask all users whether they want to compile all
> >I/O schedulers into their kernel.
> >
> The users that do not know how to handle it should not be compiling a
> kernel. If in doubt, they should read the help texts and follow the "If
> unsure" clause listed there.

If your distribution ships 2.6.x and your hardware is not supported
before 2.6.x+1 you need your own kernel.

The expectation "only kernel hackers don't use distribution kernels" is
wrong in too many cases.

"System administrator" is a target audience of the kernel configuration,
and we should make it as easy as possible for such people to compile
their own kernel.

> Jan Engelhardt

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-08-25 12:13:56

by Jens Axboe

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Thu, Aug 24 2006, David Howells wrote:
>
> Make it possible to disable the block layer. Not all embedded devices require
> it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
> the block layer to be present.

Overall, this looks good. It's definitely something that has been talked
about for years (off and on), but nobody ever did. So thanks David!

When you respin this patch, care to do it against the 'block' branch of
the git block repo?

> (*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
> block layer to do scheduling.

SCSI uses the queue as the transport even for char devices, so yes you
have to leave all of SCSI behind.

--
Jens Axboe

2006-08-25 13:09:48

by Alexey Dobriyan

[permalink] [raw]

Subject: Re: [PATCH] BLOCK: Make it possible to disable the block layer

On Fri, Aug 25, 2006 at 12:37:54PM +0200, Adrian Bunk wrote:
> On Fri, Aug 25, 2006 at 08:07:37AM +0200, Jan Engelhardt wrote:
> > >
> > >There's e.g. no reason to ask all users whether they want to compile all
> > >I/O schedulers into their kernel.
> > >
> > The users that do not know how to handle it should not be compiling a
> > kernel. If in doubt, they should read the help texts and follow the "If
> > unsure" clause listed there.
>
> If your distribution ships 2.6.x and your hardware is not supported
> before 2.6.x+1 you need your own kernel.
>
> The expectation "only kernel hackers don't use distribution kernels" is
> wrong in too many cases.
>
> "System administrator" is a target audience of the kernel configuration,
> and we should make it as easy as possible for such people to compile
> their own kernel.

This is solvable with good help texts.

config IOSCHED_PRON
tristate
The pr0n I/O scheduler is specifically tuned for one specific
task -- busy webserver shipping pr0n to customers. Distributions of
file sizes and access patterns were heavily analyzed during
development.

To make such server even more faster also select "pr0n filesystem
support" in File systems menu and read help text there.

If you aren't in pr0n industry, say N.

2006-08-25 13:41:05