Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform
On Sat, Feb 20, 2021 at 05:32:30PM +1100, Finn Thain wrote:
> Nope. Interrupt priority masking is there to place an upper bound
> interrupt latency. That's why this feature is shipping in contemporary
> hardware (e.g. ARM GIC). If you care about real time workloads on arm64,
> that may interest you.
I don't know if it's still true today, but in the past there was a very
noticeable difference in timer stability between the 68k macintosh
models with the timer interrupt at IPL 1 as compared to the models
where the timer interrupt was at IPL 6. The ability to preempt the
other interrupt handlers made the difference between a usable clock
and one that was pretty unreliable.
Brad Boyer
f...@allandria.com
Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform
On Fri, Feb 19, 2021 at 09:10:57AM +0100, Geert Uytterhoeven wrote: > Hi Michael, > > On Thu, Feb 18, 2021 at 11:11 PM Michael Schmitz wrote: > > On 19/02/21 12:19 am, Arnd Bergmann wrote: > > > drivers/net/ethernet/8390/apne.c > > > drivers/net/ethernet/8390/ax88796.c > > > drivers/net/ethernet/8390/hydra.c > > > drivers/net/ethernet/8390/mac8390.c > > > drivers/net/ethernet/8390/ne.c > > > drivers/net/ethernet/8390/zorro8390.c > > [...] > > > Most of these are normal short-lived interrupts that only transfer > > > a few bytes or schedule deferred processing of some sort. > > > Most of the scsi and network drivers process the data in > > > a softirq, so those are generally fine here, but I do see that 8390 > > > (ne2000) ethernet and the drivers/ide drivers do transfer their > > > data in hardirq context. > > > > > > Arnd > > > > 8390 ethernet drivers are widely used on m68k platforms (Amiga and > > Atari). At least on Amiga, the corresponding interrupt is a hardirq so > > I'd advise caution. That said, the 8390 drivers might benefit from some > > refactoring (the way these drivers are compiled does prevent e.g. the > > APNE driver from being used with two different variants of PCMCIA > > interfaces. I had begun some work on making IO primitives runtime > > selected two years ago but that ended up looking too ugly ...). > > > > Can't recall what IPL the 8390 interrupts operate at - Geert? > > #define IRQ_AMIGA_PORTS IRQ_AUTO_2 > > Zorro expansion boards can also use > > #define IRQ_AMIGA_EXTER IRQ_AUTO_6 > > and some boards may have a jumper to select the latter, but all Amiga > Linux drivers use IRQ_AMIGA_PORTS. The mac8390 driver will show up wherever NuBus interrupts are routed, which varies by hardware. It's frequently IRQ_AUTO_2 (due to being routed through the second VIA chip on most models), but it can be in other places on systems that don't use a second VIA chip. On the IIfx, NuBus interrupts get routed through OSS to IRQ_AUTO_3. I don't see any cases that use other interrupt levels, but some of the logic is a little harder to follow. It's not an 8390, but it looks like macmace actually uses two levels. The regular interrupt should show up at IRQ_AUTO_3 and the DMA interrupts at IRQ_AUTO_4. Most Macs only use 4 for serial, but this is an exception. Brad Boyer f...@allandria.com
Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
On Tue, Oct 20, 2020 at 08:42:53PM +0200, Laurent Vivier wrote: > Le 20/10/2020 ?? 20:32, Greg KH a ??crit??: > > On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote: > >> Le 20/10/2020 ?? 19:37, Greg KH a ??crit??: > >>> Why not fix it to work properly like other arch checks are done > >> I would be happy to do the same. > >> > >>> Put it in a .h file and do the #ifdef there. Why is this "special"? > >> > >> I don't know. > >> > > > > Yup, that would be a good start, but why is the pmac_zilog.h file > > responsible for this? Shouldn't this be in some arch-specific file > > somewhere? > > For m68k, MACH_IS_MAC is defined in arch/m68k/include/asm/setup.h > > If I want to define it for any other archs I don't know in which file we > can put it. > > But as m68k mac is only sharing drivers with pmac perhaps we can put > this in arch/powerpc/include/asm/setup.h? Wouldn't it be better to rearrange this code to only run if the devices are present? This is a macio driver on pmac and a platform driver on mac, so shouldn't it be possible to only run this code when the appropriate entries are present in the right data structures? I didn't look at a lot of the other serial drivers, but some other mac drivers have recently been updated to no longer have MACH_IS_MAC checks due to being converted to platform drivers. Brad Boyer b...@allandria.com
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Mon, Jul 01, 2013 at 05:48:22PM +1000, Finn Thain wrote:
>
> On Sun, 30 Jun 2013, Brad Boyer wrote:
>
> > On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote:
> > >
> > > if (iop_scc_present) {
> > > printk("IOP: detected SCC IOP at %p\n", iop_base[IOP_NUM_SCC]);
> > > + alloc_msg_queue(IOP_NUM_SCC);
> >
> > Technically, this isn't actually useful. As long as we never start this
> > IOP, it can't ever send or be sent any messages.
>
> That assumes that the SCC IOP is in a stopped state after iop_preinit().
> But I don't think that's the case. If it is technically possible to
> exchange messages with a device in bypass mode (?) then I think the code
> above is correct.
You're right. The value we write during iop_preinit actually leaves the
IOP running. I'm not sure why we did that. I wonder if it's possible to
put the ISM IOP into bypass mode and still use the ADB driver. Then we
could possibly use the normal SWIM driver on these systems.
> > > @@ -315,6 +307,9 @@ void __init iop_register_interrupts(void)
> > > } else {
> > > printk("IOP: the ISM IOP seems to be alive.\n");
> > > }
> >
> > The if/else above isn't useful if it is run before the call to
> > iop_start. However, it's also useless if it is called immediately after
> > the call to iop_alive which is now below. It was supposed to eventually
> > be called in the background on a regular schedule, but that never
> > happened.
> >
>
> I agree. That if/else statement and the conditional printk's should be
> omitted.
>
> I had thought that in the existing code the interrupt service routine was
> registered before the call to iop_start() but in fact iop_start() happens
> first. Looks like a bug to me. The interrupt handler needs to be able to
> acknowledge unsolicited messages...
Yes, we definitely should install the IRQ handler before calling iop_start.
Brad Boyer
f...@allandria.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Mon, Jul 01, 2013 at 05:46:48PM +1000, Finn Thain wrote:
>
> On Sun, 30 Jun 2013, Geert Uytterhoeven wrote:
>
> > -
> > -/*
> > - * Register the interrupt handler for the IOPs.
> > - * TODO: might be wrong for non-OSS machines. Anyone?
> > - */
> > -
> > -void __init iop_register_interrupts(void)
> > -{
> > - if (iop_ism_present) {
> > + /*
> > +* Register the interrupt handler for the IOPs.
> > +* TODO: might be wrong for non-OSS machines. Anyone?
>
> My testing with a non-OSS machine (Quadra 950) indicates that the TODO is
> obsolete. And the comment "register the interrupt handler for the IOPs" is
> a bit silly. It merely re-phrases the code. Otherwise, this patch looks
> good to me. Thanks.
The code was all originally written and tested only on the IIfx. That's
all JMT had, and at the time it was all I had as well. I have since
acquired a Quadra 950. Lots of these comments are just out of date. I
know it got tested on either a Quadra 900 or Quadra 950 after that
comment was put in the source.
Brad Boyer
f...@allandria.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote:
> Currently the IOP message pool and queues are allocated statically,
> wasting ca. 5 KiB when running a Mac or multi-platform kernel on a machine
> not having a Mac IOP. Convert them to conditional dynamic memory
> allocations to fix this.
>
> As kzalloc() returns zeroed memory, there's no need to initialize (parts of)
> the allocated structures to zeroes.
>
> This required moving the call to iop_init() from mac_identify() to
> mac_platform_init() (slab nor bootmem are available at mac_identify() call
> time), and allowed to integrate iop_register_interrupts() into iop_init().
Just a couple very minor comments. I haven't tested it, but I was involved
with the original implementation and testing of this code.
> Signed-off-by: Geert Uytterhoeven
> ---
> Untested due to lack of hardware
>
> arch/m68k/include/asm/mac_iop.h |2 --
> arch/m68k/mac/config.c |3 ++-
> arch/m68k/mac/iop.c | 57
> ++-
> arch/m68k/mac/macints.c |1 -
> 4 files changed, 28 insertions(+), 35 deletions(-)
>
> diff --git a/arch/m68k/include/asm/mac_iop.h b/arch/m68k/include/asm/mac_iop.h
> index fde874a..a2c7e6f 100644
> --- a/arch/m68k/include/asm/mac_iop.h
> +++ b/arch/m68k/include/asm/mac_iop.h
> @@ -159,6 +159,4 @@ extern void iop_upload_code(uint, __u8 *, uint, __u16);
> extern void iop_download_code(uint, __u8 *, uint, __u16);
> extern __u8 *iop_compare_code(uint, __u8 *, uint, __u16);
>
> -extern void iop_register_interrupts(void);
> -
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
> index afb95d5..a8d62a8 100644
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -925,7 +925,6 @@ static void __init mac_identify(void)
> printk(KERN_DEBUG " Machine ID: %ld CPUid: 0x%lx memory size: 0x%lx\n",
> mac_bi_data.id, mac_bi_data.cpuid, mac_bi_data.memsize);
>
> - iop_init();
> via_init();
> oss_init();
> psc_init();
> @@ -983,6 +982,8 @@ int __init mac_platform_init(void)
> if (!MACH_IS_MAC)
> return -ENODEV;
>
> + iop_init();
> +
> /*
>* Serial devices
>*/
> diff --git a/arch/m68k/mac/iop.c b/arch/m68k/mac/iop.c
> index 8a4c446..6cc3055 100644
> --- a/arch/m68k/mac/iop.c
> +++ b/arch/m68k/mac/iop.c
> @@ -104,6 +104,7 @@
> * should execute quickly.)
> */
>
> +#include
> #include
> #include
> #include
> @@ -142,9 +143,9 @@ static volatile struct mac_iop *iop_base[NUM_IOPS];
> * IOP message queues
> */
>
> -static struct iop_msg iop_msg_pool[NUM_IOP_MSGS];
> -static struct iop_msg *iop_send_queue[NUM_IOPS][NUM_IOP_CHAN];
> -static struct listener iop_listeners[NUM_IOPS][NUM_IOP_CHAN];
> +static struct iop_msg *iop_msg_pool;
> +static struct iop_msg **iop_send_queue[NUM_IOPS];
> +static struct listener *iop_listeners[NUM_IOPS];
>
> irqreturn_t iop_ism_irq(int, void *);
>
> @@ -260,47 +261,38 @@ void __init iop_preinit(void)
> }
> }
>
> +static void __init alloc_msg_queue(int iop_num)
> +{
> + iop_send_queue[iop_num] =
> + kzalloc(NUM_IOP_CHAN * sizeof(**iop_send_queue), GFP_KERNEL);
> + iop_listeners[iop_num] =
> + kzalloc(NUM_IOP_CHAN * sizeof(**iop_listeners), GFP_KERNEL);
> +}
> +
> /*
> * Initialize the IOPs, if present.
> */
>
> void __init iop_init(void)
> {
> - int i;
> + if (!iop_scc_present && !iop_ism_present)
> + return;
> +
> + iop_msg_pool = kzalloc(NUM_IOP_MSGS * sizeof(*iop_msg_pool),
> +GFP_KERNEL);
>
> if (iop_scc_present) {
> printk("IOP: detected SCC IOP at %p\n", iop_base[IOP_NUM_SCC]);
> + alloc_msg_queue(IOP_NUM_SCC);
Technically, this isn't actually useful. As long as we never start this
IOP, it can't ever send or be sent any messages. We currently leave the
SCC IOP in bypass mode and access the SCC chip directly.
Perhaps it would be better to allocate it at the beginning of iop_start
if it is not already allocated?
> }
> if (iop_ism_present) {
> printk("IOP: detected ISM IOP at %p\n", iop_base[IOP_NUM_ISM]);
> - iop_start(iop_base[IOP_NUM_ISM]);
> - iop_alive(iop_base[IOP_NUM_ISM]); /* clears the alive flag */
> - }
> -
> - /* Make the whole pool available and empty the queues */
> -
> - for (i = 0 ; i < NUM_IOP_MSGS ; i++) {
> - iop_msg_pool[i].status = IOP_MSGSTATUS_UNUSED;
> - }
> + alloc_msg_queue(IOP_NUM_ISM);
>
> - for (i = 0 ; i < NUM_IOP_CHAN ; i++) {
> - iop_send_queue[IOP_NUM_SCC][i] = NULL;
> - iop_send_queue[IOP_NUM_ISM][i] = NULL;
> - iop_listeners[IOP_NUM_SCC][i].devname = NULL;
> - iop_listeners[IOP_NUM_SCC][i].handler = NULL;
> - iop_listeners[IOP_NUM_ISM][i].devname = NULL;
> -
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote:
Currently the IOP message pool and queues are allocated statically,
wasting ca. 5 KiB when running a Mac or multi-platform kernel on a machine
not having a Mac IOP. Convert them to conditional dynamic memory
allocations to fix this.
As kzalloc() returns zeroed memory, there's no need to initialize (parts of)
the allocated structures to zeroes.
This required moving the call to iop_init() from mac_identify() to
mac_platform_init() (slab nor bootmem are available at mac_identify() call
time), and allowed to integrate iop_register_interrupts() into iop_init().
Just a couple very minor comments. I haven't tested it, but I was involved
with the original implementation and testing of this code.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
Untested due to lack of hardware
arch/m68k/include/asm/mac_iop.h |2 --
arch/m68k/mac/config.c |3 ++-
arch/m68k/mac/iop.c | 57
++-
arch/m68k/mac/macints.c |1 -
4 files changed, 28 insertions(+), 35 deletions(-)
diff --git a/arch/m68k/include/asm/mac_iop.h b/arch/m68k/include/asm/mac_iop.h
index fde874a..a2c7e6f 100644
--- a/arch/m68k/include/asm/mac_iop.h
+++ b/arch/m68k/include/asm/mac_iop.h
@@ -159,6 +159,4 @@ extern void iop_upload_code(uint, __u8 *, uint, __u16);
extern void iop_download_code(uint, __u8 *, uint, __u16);
extern __u8 *iop_compare_code(uint, __u8 *, uint, __u16);
-extern void iop_register_interrupts(void);
-
#endif /* __ASSEMBLY__ */
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index afb95d5..a8d62a8 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -925,7 +925,6 @@ static void __init mac_identify(void)
printk(KERN_DEBUG Machine ID: %ld CPUid: 0x%lx memory size: 0x%lx\n,
mac_bi_data.id, mac_bi_data.cpuid, mac_bi_data.memsize);
- iop_init();
via_init();
oss_init();
psc_init();
@@ -983,6 +982,8 @@ int __init mac_platform_init(void)
if (!MACH_IS_MAC)
return -ENODEV;
+ iop_init();
+
/*
* Serial devices
*/
diff --git a/arch/m68k/mac/iop.c b/arch/m68k/mac/iop.c
index 8a4c446..6cc3055 100644
--- a/arch/m68k/mac/iop.c
+++ b/arch/m68k/mac/iop.c
@@ -104,6 +104,7 @@
* should execute quickly.)
*/
+#include linux/slab.h
#include linux/types.h
#include linux/kernel.h
#include linux/mm.h
@@ -142,9 +143,9 @@ static volatile struct mac_iop *iop_base[NUM_IOPS];
* IOP message queues
*/
-static struct iop_msg iop_msg_pool[NUM_IOP_MSGS];
-static struct iop_msg *iop_send_queue[NUM_IOPS][NUM_IOP_CHAN];
-static struct listener iop_listeners[NUM_IOPS][NUM_IOP_CHAN];
+static struct iop_msg *iop_msg_pool;
+static struct iop_msg **iop_send_queue[NUM_IOPS];
+static struct listener *iop_listeners[NUM_IOPS];
irqreturn_t iop_ism_irq(int, void *);
@@ -260,47 +261,38 @@ void __init iop_preinit(void)
}
}
+static void __init alloc_msg_queue(int iop_num)
+{
+ iop_send_queue[iop_num] =
+ kzalloc(NUM_IOP_CHAN * sizeof(**iop_send_queue), GFP_KERNEL);
+ iop_listeners[iop_num] =
+ kzalloc(NUM_IOP_CHAN * sizeof(**iop_listeners), GFP_KERNEL);
+}
+
/*
* Initialize the IOPs, if present.
*/
void __init iop_init(void)
{
- int i;
+ if (!iop_scc_present !iop_ism_present)
+ return;
+
+ iop_msg_pool = kzalloc(NUM_IOP_MSGS * sizeof(*iop_msg_pool),
+GFP_KERNEL);
if (iop_scc_present) {
printk(IOP: detected SCC IOP at %p\n, iop_base[IOP_NUM_SCC]);
+ alloc_msg_queue(IOP_NUM_SCC);
Technically, this isn't actually useful. As long as we never start this
IOP, it can't ever send or be sent any messages. We currently leave the
SCC IOP in bypass mode and access the SCC chip directly.
Perhaps it would be better to allocate it at the beginning of iop_start
if it is not already allocated?
}
if (iop_ism_present) {
printk(IOP: detected ISM IOP at %p\n, iop_base[IOP_NUM_ISM]);
- iop_start(iop_base[IOP_NUM_ISM]);
- iop_alive(iop_base[IOP_NUM_ISM]); /* clears the alive flag */
- }
-
- /* Make the whole pool available and empty the queues */
-
- for (i = 0 ; i NUM_IOP_MSGS ; i++) {
- iop_msg_pool[i].status = IOP_MSGSTATUS_UNUSED;
- }
+ alloc_msg_queue(IOP_NUM_ISM);
- for (i = 0 ; i NUM_IOP_CHAN ; i++) {
- iop_send_queue[IOP_NUM_SCC][i] = NULL;
- iop_send_queue[IOP_NUM_ISM][i] = NULL;
- iop_listeners[IOP_NUM_SCC][i].devname = NULL;
- iop_listeners[IOP_NUM_SCC][i].handler = NULL;
- iop_listeners[IOP_NUM_ISM][i].devname = NULL;
- iop_listeners[IOP_NUM_ISM][i].handler = NULL;
- }
-}
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Mon, Jul 01, 2013 at 05:46:48PM +1000, Finn Thain wrote:
On Sun, 30 Jun 2013, Geert Uytterhoeven wrote:
-
-/*
- * Register the interrupt handler for the IOPs.
- * TODO: might be wrong for non-OSS machines. Anyone?
- */
-
-void __init iop_register_interrupts(void)
-{
- if (iop_ism_present) {
+ /*
+* Register the interrupt handler for the IOPs.
+* TODO: might be wrong for non-OSS machines. Anyone?
My testing with a non-OSS machine (Quadra 950) indicates that the TODO is
obsolete. And the comment register the interrupt handler for the IOPs is
a bit silly. It merely re-phrases the code. Otherwise, this patch looks
good to me. Thanks.
The code was all originally written and tested only on the IIfx. That's
all JMT had, and at the time it was all I had as well. I have since
acquired a Quadra 950. Lots of these comments are just out of date. I
know it got tested on either a Quadra 900 or Quadra 950 after that
comment was put in the source.
Brad Boyer
f...@allandria.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k/mac: Allocate IOP message pool and queues dynamically
On Mon, Jul 01, 2013 at 05:48:22PM +1000, Finn Thain wrote:
On Sun, 30 Jun 2013, Brad Boyer wrote:
On Sun, Jun 30, 2013 at 12:02:22PM +0200, Geert Uytterhoeven wrote:
if (iop_scc_present) {
printk(IOP: detected SCC IOP at %p\n, iop_base[IOP_NUM_SCC]);
+ alloc_msg_queue(IOP_NUM_SCC);
Technically, this isn't actually useful. As long as we never start this
IOP, it can't ever send or be sent any messages.
That assumes that the SCC IOP is in a stopped state after iop_preinit().
But I don't think that's the case. If it is technically possible to
exchange messages with a device in bypass mode (?) then I think the code
above is correct.
You're right. The value we write during iop_preinit actually leaves the
IOP running. I'm not sure why we did that. I wonder if it's possible to
put the ISM IOP into bypass mode and still use the ADB driver. Then we
could possibly use the normal SWIM driver on these systems.
@@ -315,6 +307,9 @@ void __init iop_register_interrupts(void)
} else {
printk(IOP: the ISM IOP seems to be alive.\n);
}
The if/else above isn't useful if it is run before the call to
iop_start. However, it's also useless if it is called immediately after
the call to iop_alive which is now below. It was supposed to eventually
be called in the background on a regular schedule, but that never
happened.
I agree. That if/else statement and the conditional printk's should be
omitted.
I had thought that in the existing code the interrupt service routine was
registered before the call to iop_start() but in fact iop_start() happens
first. Looks like a bug to me. The interrupt handler needs to be able to
acknowledge unsolicited messages...
Yes, we definitely should install the IRQ handler before calling iop_start.
Brad Boyer
f...@allandria.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] readdir() as an inode operation
On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote: > > This is a first try to move readdir() to become an inode operation. This is > > necessary for a VFS implementation of "something like union-mounts" where a > > readdir() needs to read the directory contents of multiple directories. > > Besides that the new interface is no longer giving the struct file to the > > filesystem implementations anymore. > > > > Comments, please? > Hmm, are you sure there are no users which keep some per-struct-file > information for directories? File offset is one such obvious thing which > you've handled but actually filesystem with more complicated structure > of directory may remember some hints about where we really are, keep > some readahead information or so... The hfsplus code keeps some extra data in the ->private_data of directories, although I've lost track of the exact benefit from not looking at the code in some years. As I recall it was a performance enhancement due to the fact that the data for all directories is effectively in a single file. I believe it was easier to keep the current position as a structure rather than just an offset and be careful about the tracking. The hfs code is almost identical to the hfsplus code in this area. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] readdir() as an inode operation
On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote: This is a first try to move readdir() to become an inode operation. This is necessary for a VFS implementation of something like union-mounts where a readdir() needs to read the directory contents of multiple directories. Besides that the new interface is no longer giving the struct file to the filesystem implementations anymore. Comments, please? Hmm, are you sure there are no users which keep some per-struct-file information for directories? File offset is one such obvious thing which you've handled but actually filesystem with more complicated structure of directory may remember some hints about where we really are, keep some readahead information or so... The hfsplus code keeps some extra data in the -private_data of directories, although I've lost track of the exact benefit from not looking at the code in some years. As I recall it was a performance enhancement due to the fact that the data for all directories is effectively in a single file. I believe it was easier to keep the current position as a structure rather than just an offset and be careful about the tracking. The hfs code is almost identical to the hfsplus code in this area. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> Pointless here means that _I_ don't see the point. Maybe there are
> valid uses for extended attributes. If there are, noone has explained
> them to me yet.
The users of extended attributes that I've dealt with are ACL support
and SELinux. These both use extended attributes under the covers. It's
just not immediately obvious if you aren't looking.
Brad Boyer
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote: Pointless here means that _I_ don't see the point. Maybe there are valid uses for extended attributes. If there are, noone has explained them to me yet. The users of extended attributes that I've dealt with are ACL support and SELinux. These both use extended attributes under the covers. It's just not immediately obvious if you aren't looking. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 19/33] NuBus header update
On Wed, May 02, 2007 at 08:47:13PM +0100, James Simmons wrote:
> Will we see nubus ported over to the driver model soon :-)
I think it will happen eventually. However, my first priority
personally is to get the macio code working on non-PCI macs
to get the onboard stuff onto the driver model. I did look at
it, and NuBus does lend itself to this conversion due to the
fact that it does in general have devices that can be detected
at runtime and a lot of generic infrastructure. It's just a
matter of priorities and a lack of time all around.
Brad Boyer
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 19/33] NuBus header update
On Wed, May 02, 2007 at 08:47:13PM +0100, James Simmons wrote: Will we see nubus ported over to the driver model soon :-) I think it will happen eventually. However, my first priority personally is to get the macio code working on non-PCI macs to get the onboard stuff onto the driver model. I did look at it, and NuBus does lend itself to this conversion due to the fact that it does in general have devices that can be detected at runtime and a lot of generic infrastructure. It's just a matter of priorities and a lack of time all around. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 08:54:10PM -0400, David Woodhouse wrote: > But why? There's nothing special and magical about the number 64 and the > letters 't' 't' 'y' and 'S'. And if you have broken software which only > works with ttyS[0123] then you can still create device nodes or symlinks > to work around that. I never claimed there was anything magical about those particular values and I don't intend to do that in the future. The issue is one of standardization. As an example, Solaris does use the same device names for both Zilog 8530 and 8250 ports in spite of naming ethernet devices based on the hardware type. I just checked the man pages on a Solaris 9 system to be sure. The issue is that the naming should be consistent. I shouldn't need to know what the hardware is to use what is fundamentally an abstraction of "serial port" as far as the user is concerned. On Solaris, I can say "/dev/term/a" and know that I will get the first serial port if it is available without needing to care if it is the zs, se or asy driver talking to the hardware. Note that I'm not suggesting we should do what Solaris does because Sun decided it was the way to do it. I'm just pointing out an example. > If you're on a platform where 8250 serial ports _cannot_ exist, then > abusing the 8250 driver's numbers would perhaps be workable, if a little > strange -- but 8250 ports are ubiquitous. You can attach them to just > about anything, of any architecture, that Linux runs on. Except perhaps > S390. The availability of the specific chip in question is a red herring in my opinion. I do understand that 8250 compatible chips are very common and are the most likely serial chips to be used with Linux. However, I will point out that the define is TTY_MAJOR, not 8250_MAJOR. It seems to me that whoever named it was thinking in more generic terms. > Yes, it would be theoretically possible to come up with a way to share > minor numbers so we can use 'ttyS0' for the first serial port regardless > of what type of port it is. We could take the arch-specific hack that > SPARC has and try to move it to generic code. But what's the point? The point is that people are used to having "ttyS0" mean the first onboard serial port. I firmly believe that the user-space programs should need to know as little as possible about the hardware, and it would be nice to abstract that away from the end user as well. We've moved toward commonality and standarization in other areas, and I think we should here as well. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 07:28:36PM -0400, David Woodhouse wrote: > I agree to a certain extent -- but then again, why should a user know or > care about the name /dev/ttyS0 _either_? A GUI PPP dialer should be > listing the available serial ports in the system whatever their names > are. The moment you do serial console, the user needs to know. I would hate having to have console=ttyPZ0 in my kernel command line. Does that even work? I didn't see a change to the console setup in your patch. Serial is for much more than modems and PDA sync. In fact, I would think that many more Linux systems these days use serial for console than for any other purpose due to the use of such setups in large data centers and the reduction in serial peripherals for desktop computers. > And nobody _forces_ you to use the name ttyPZ0. If you really want, you > can call it ttyS0 just mknod /dev/ttyS0 204 192 > > You could even have udev rules which share the /dev/ttyS$N namespace > between _all_ kinds of serial ports, if you really want to. > > Abusing the 8250 device numbers prevents the 8250 module from being > loaded at the same time as pmac_zilog, and means you can't have both > internal port and PCMCIA or PCI 8250 ports active at the same time. The TTY_MAJOR should have never belonged to 8250.c in the first place. I know it's just my opinion, but I think this major device should be owned by the serial core, and it shouldn't matter what chip drives each individual port. Each hardware driver should just register with the core how many ports it has and should be allocated from the same range. This situation is purely a side-effect of the fact that all the original Linux supported hardware used the 8250 driver and everyone who didn't use 8250 was marginalized enough that they got ignored. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 08:12:48PM -0400, David Woodhouse wrote: > On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote: > > Sparc does the same thing, it's a common convention and you really > > should not break it. > > I thought that argument was lost many years ago. It _used_ to be a > common convention; we got better. This argument was made and lost as you say. The problem is that the resolution was a decision from on high. For the most part, everyone kept their original opinion and nothing was truly resolved. I think there was some resentment on the part of the losing side because they felt their opinions weren't seriously considered. Please correct me if my impressions of that were wrong. I was not directly involved in such arguments at the time. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 07:57:22PM -0400, David Woodhouse wrote: > > The TTY_MAJOR should have never belonged to 8250.c in the first place. > > I know it's just my opinion, but I think this major device should be > > owned by the serial core, and it shouldn't matter what chip drives each > > individual port. Each hardware driver should just register with the > > core how many ports it has and should be allocated from the same range. > > Yeah, because that works out really well for Ethernet devices and SCSI > disks, with different numbers every day of the week according to what > order we happen to load drivers in. :) It just leads to the problem ethernet has on BSD/Solaris/etc. You have to ask yourself "is the ethernet on this system le0 or hme0 or maybe something else entirely?" in this case. I agree it does solve the issue of detection order breaking the configuration, but it is less than ideal. I think the issue of the devices shuffling around is less likely to be a problem on serial, although we don't have the nice uniqueness of hardware identifiers that was used to do device renaming in ethernet. I suppose my opinion on this shows that I didn't come from the x86 side of Linux. The breakdown on this argument seems to have always been that the x86 people wanted 8250 to own ttyS* and most others wanted it shared. I know it was that way when m68k tried to merge in their serial framework that did allow such sharing across any number of hardware drivers. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 07:57:22PM -0400, David Woodhouse wrote: The TTY_MAJOR should have never belonged to 8250.c in the first place. I know it's just my opinion, but I think this major device should be owned by the serial core, and it shouldn't matter what chip drives each individual port. Each hardware driver should just register with the core how many ports it has and should be allocated from the same range. Yeah, because that works out really well for Ethernet devices and SCSI disks, with different numbers every day of the week according to what order we happen to load drivers in. :) It just leads to the problem ethernet has on BSD/Solaris/etc. You have to ask yourself is the ethernet on this system le0 or hme0 or maybe something else entirely? in this case. I agree it does solve the issue of detection order breaking the configuration, but it is less than ideal. I think the issue of the devices shuffling around is less likely to be a problem on serial, although we don't have the nice uniqueness of hardware identifiers that was used to do device renaming in ethernet. I suppose my opinion on this shows that I didn't come from the x86 side of Linux. The breakdown on this argument seems to have always been that the x86 people wanted 8250 to own ttyS* and most others wanted it shared. I know it was that way when m68k tried to merge in their serial framework that did allow such sharing across any number of hardware drivers. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 08:12:48PM -0400, David Woodhouse wrote: On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote: Sparc does the same thing, it's a common convention and you really should not break it. I thought that argument was lost many years ago. It _used_ to be a common convention; we got better. This argument was made and lost as you say. The problem is that the resolution was a decision from on high. For the most part, everyone kept their original opinion and nothing was truly resolved. I think there was some resentment on the part of the losing side because they felt their opinions weren't seriously considered. Please correct me if my impressions of that were wrong. I was not directly involved in such arguments at the time. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 07:28:36PM -0400, David Woodhouse wrote: I agree to a certain extent -- but then again, why should a user know or care about the name /dev/ttyS0 _either_? A GUI PPP dialer should be listing the available serial ports in the system whatever their names are. The moment you do serial console, the user needs to know. I would hate having to have console=ttyPZ0 in my kernel command line. Does that even work? I didn't see a change to the console setup in your patch. Serial is for much more than modems and PDA sync. In fact, I would think that many more Linux systems these days use serial for console than for any other purpose due to the use of such setups in large data centers and the reduction in serial peripherals for desktop computers. And nobody _forces_ you to use the name ttyPZ0. If you really want, you can call it ttyS0 just mknod /dev/ttyS0 204 192 You could even have udev rules which share the /dev/ttyS$N namespace between _all_ kinds of serial ports, if you really want to. Abusing the 8250 device numbers prevents the 8250 module from being loaded at the same time as pmac_zilog, and means you can't have both internal port and PCMCIA or PCI 8250 ports active at the same time. The TTY_MAJOR should have never belonged to 8250.c in the first place. I know it's just my opinion, but I think this major device should be owned by the serial core, and it shouldn't matter what chip drives each individual port. Each hardware driver should just register with the core how many ports it has and should be allocated from the same range. This situation is purely a side-effect of the fact that all the original Linux supported hardware used the 8250 driver and everyone who didn't use 8250 was marginalized enough that they got ignored. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
On Tue, Apr 03, 2007 at 08:54:10PM -0400, David Woodhouse wrote: But why? There's nothing special and magical about the number 64 and the letters 't' 't' 'y' and 'S'. And if you have broken software which only works with ttyS[0123] then you can still create device nodes or symlinks to work around that. I never claimed there was anything magical about those particular values and I don't intend to do that in the future. The issue is one of standardization. As an example, Solaris does use the same device names for both Zilog 8530 and 8250 ports in spite of naming ethernet devices based on the hardware type. I just checked the man pages on a Solaris 9 system to be sure. The issue is that the naming should be consistent. I shouldn't need to know what the hardware is to use what is fundamentally an abstraction of serial port as far as the user is concerned. On Solaris, I can say /dev/term/a and know that I will get the first serial port if it is available without needing to care if it is the zs, se or asy driver talking to the hardware. Note that I'm not suggesting we should do what Solaris does because Sun decided it was the way to do it. I'm just pointing out an example. If you're on a platform where 8250 serial ports _cannot_ exist, then abusing the 8250 driver's numbers would perhaps be workable, if a little strange -- but 8250 ports are ubiquitous. You can attach them to just about anything, of any architecture, that Linux runs on. Except perhaps S390. The availability of the specific chip in question is a red herring in my opinion. I do understand that 8250 compatible chips are very common and are the most likely serial chips to be used with Linux. However, I will point out that the define is TTY_MAJOR, not 8250_MAJOR. It seems to me that whoever named it was thinking in more generic terms. Yes, it would be theoretically possible to come up with a way to share minor numbers so we can use 'ttyS0' for the first serial port regardless of what type of port it is. We could take the arch-specific hack that SPARC has and try to move it to generic code. But what's the point? The point is that people are used to having ttyS0 mean the first onboard serial port. I firmly believe that the user-space programs should need to know as little as possible about the hardware, and it would be nice to abstract that away from the end user as well. We've moved toward commonality and standarization in other areas, and I think we should here as well. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Sat, Dec 02, 2006 at 09:56:27PM -0500, Jeff Layton wrote: > My main reasoning for doing this was that the structures involved are > per-superblock. There is virtually no reason that a filesystem would > ever need to touch these structures in another filesystem. I don't think this is relevant to the issue. I wouldn't expect that if you allow people to use this functionality that they would go poking around in other filesystems. I would expect people to use it on the filesystem they are writing. > So, this is essentially a service to make it easy for filesystems to > implement i_ino uniqueness. I'm not terribly interested in making things > easier for proprietary filesystems, so I don't see a real reason to make > this available to them. They can always implement their own scheme to do > this. This sounds slightly petty to me. For example, generic_file_read() is there just to make it easier to implement the read callback, but it isn't required. In fact, I would think that any filesystem complex enough to be worth making proprietary would not use it. However, that doesn't seem to me to be a good argument for marking it GPL-only. The functionality in question is easier to reimplement, but that doesn't make it right to force it on people just because of a license choice. > I'm certainly open to discussion though. Is there a compelling reason to > open this up to proprietary software authors? I don't think there is a compelling reason to open it up since the functionality could be reimplemented if needed, but I also think the only reason it is being marked GPL-only is the very common attitude that there should not be any proprietary modules. To be honest, I think it looks bad for someone associated with redhat to be suggesting that life should be made more difficult for those who write proprietary software on Linux. The support from commercial software is a major reason for the success of the RHEL product line. I can't imagine that this attitude will affect support from software companies as long as there is a demand for software on Linux, but it isn't exactly supportive. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Fri, Dec 01, 2006 at 12:21:36PM -0500, Jeff Layton wrote:
> Here's an updated (but untested) patch based on your suggestions. I also went
> ahead and made the exported symbols GPL-only since that seems like it would be
> appropriate here. Any further thoughts on it?
I don't know that this is a good idea. I know this isn't likely to be
a popular statement, but I think that there should be at least some
minor justification to making a symbol GPL-only (it won't take much).
This seems like exactly the sort of thing that should be a generic
service available to all filesystem implementors whether it's GPL or
not. The usual justification for GPL-only is that it's something
random modules shouldn't be touching anyway, but it's something that
some part of the tree which could be a module needs.
Brad Boyer
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Fri, Dec 01, 2006 at 12:21:36PM -0500, Jeff Layton wrote: Here's an updated (but untested) patch based on your suggestions. I also went ahead and made the exported symbols GPL-only since that seems like it would be appropriate here. Any further thoughts on it? I don't know that this is a good idea. I know this isn't likely to be a popular statement, but I think that there should be at least some minor justification to making a symbol GPL-only (it won't take much). This seems like exactly the sort of thing that should be a generic service available to all filesystem implementors whether it's GPL or not. The usual justification for GPL-only is that it's something random modules shouldn't be touching anyway, but it's something that some part of the tree which could be a module needs. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Sat, Dec 02, 2006 at 09:56:27PM -0500, Jeff Layton wrote: My main reasoning for doing this was that the structures involved are per-superblock. There is virtually no reason that a filesystem would ever need to touch these structures in another filesystem. I don't think this is relevant to the issue. I wouldn't expect that if you allow people to use this functionality that they would go poking around in other filesystems. I would expect people to use it on the filesystem they are writing. So, this is essentially a service to make it easy for filesystems to implement i_ino uniqueness. I'm not terribly interested in making things easier for proprietary filesystems, so I don't see a real reason to make this available to them. They can always implement their own scheme to do this. This sounds slightly petty to me. For example, generic_file_read() is there just to make it easier to implement the read callback, but it isn't required. In fact, I would think that any filesystem complex enough to be worth making proprietary would not use it. However, that doesn't seem to me to be a good argument for marking it GPL-only. The functionality in question is easier to reimplement, but that doesn't make it right to force it on people just because of a license choice. I'm certainly open to discussion though. Is there a compelling reason to open this up to proprietary software authors? I don't think there is a compelling reason to open it up since the functionality could be reimplemented if needed, but I also think the only reason it is being marked GPL-only is the very common attitude that there should not be any proprietary modules. To be honest, I think it looks bad for someone associated with redhat to be suggesting that life should be made more difficult for those who write proprietary software on Linux. The support from commercial software is a major reason for the success of the RHEL product line. I can't imagine that this attitude will affect support from software companies as long as there is a demand for software on Linux, but it isn't exactly supportive. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PPC64 iSeries: cleanup viopath
On Tue, Mar 15, 2005 at 11:43:10AM -0600, Linas Vepstas wrote:
> FWIW, keep in mind that a cache miss due to large structures not fitting
> is a zillion times more expensive than byte-aligning in the cpu
> (even if byte operands had a cpu perf overhead, which I don't think
> they do on ppc).
Actually, there is a small overhead to bytes if you make them signed.
That's why char is unsigned by default on ppc.
Brad Boyer
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PPC64 iSeries: cleanup viopath
On Tue, Mar 15, 2005 at 11:43:10AM -0600, Linas Vepstas wrote: FWIW, keep in mind that a cache miss due to large structures not fitting is a zillion times more expensive than byte-aligning in the cpu (even if byte operands had a cpu perf overhead, which I don't think they do on ppc). Actually, there is a small overhead to bytes if you make them signed. That's why char is unsigned by default on ppc. Brad Boyer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
Aaron Lehmann wrote: > On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote: > > > initrd is an unnecessary pain in the ass for most people. > > > It had better not become mandatory. > > > > You would not notice the difference, only your kernel would be > > a bit smaller and the RRPART ioctl disappears. > > Would I not notice the difference as a user, as a sysadmin, as a > kernel builder, as a kernel hacker, or all of the above? If I understand the status of stuff correctly, I think this would make it a lot more painful to admin if it became a requirement to use initrd on everything just to be able to boot. If you've ever seen the way some of the bootloaders for alterate platforms (like ppc and 68k) handle booting, you'd see what a pain it can be to have anything more than a simple string of options getting passed to the kernel. It's particularly bad on some of the embedded ppc platforms. I suspect that if this happened, it would never be allowed into many people's trees, because it would be worth their effort to maintain different code so they don't have to squeeze an initrd on flash along with their kernel and root filesystem. If I'm missing the boat here, please tell me, but it sure seems like a bad idea to me. Brad Boyer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
Aaron Lehmann wrote: On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote: initrd is an unnecessary pain in the ass for most people. It had better not become mandatory. You would not notice the difference, only your kernel would be a bit smaller and the RRPART ioctl disappears. Would I not notice the difference as a user, as a sysadmin, as a kernel builder, as a kernel hacker, or all of the above? If I understand the status of stuff correctly, I think this would make it a lot more painful to admin if it became a requirement to use initrd on everything just to be able to boot. If you've ever seen the way some of the bootloaders for alterate platforms (like ppc and 68k) handle booting, you'd see what a pain it can be to have anything more than a simple string of options getting passed to the kernel. It's particularly bad on some of the embedded ppc platforms. I suspect that if this happened, it would never be allowed into many people's trees, because it would be worth their effort to maintain different code so they don't have to squeeze an initrd on flash along with their kernel and root filesystem. If I'm missing the boat here, please tell me, but it sure seems like a bad idea to me. Brad Boyer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 64-bit block sizes on 32-bit systems
Steve Lord wrote:
> Just a brief add to the discussion, besides which I have a vested interest
> in this!
I'll add my little comments as well, and hopefully not start a flamewar... :)
[snip comments about blocksize, etc.]
Here's a real-life example of something that most of you will probably hate
me for mentioning:
HFS uses variable sized blocks (made up of multiple 512 byte sectors), but
stores block numbers as a 16 bit value. (I know, everyone will say, "We're
talking about moving from 32 to 64 bits." Keep listening.) This gave great
performance on the then current massive storage of a 20M drive. However,
when it became possible to get the absolutely gigantic hard drive of 1G,
it became more and more obvious that it was a drawback that was causing
a huge amount of wasted space. Apple had to design a new filesystem (HFS+)
that was able to represent blocks with a 32 bit number to overcome the
effective limitation on how big a filesystem could be. It's getting to
the point now that it's easily possible to put together a disk array that
is large enough that even referring to blocks with a 32 bit value requires
relatively large blocks. I don't know if we have very many filesystems that
would support this feature, but it will become important a lot sooner than
anyone may be thinking.
Obviously this case isn't a perfect fit for the situation, since HFS was
designed to be read by 32 bit machines, and the upgrade to 32 bits didn't
give a CPU penalty, just a bus bandwidth problem. Also, I'm coming from
a platform that actually can do a decent job of 64 bit, unlike x86, but
we shouldn't disallow people from doing bigger and better things. It's
become very popular lately to position Linux as an enterprise-ready system,
and this is something that will be expected. People will want to access
a multi-TB database as a single file, as well as other things that may
seem crazy to most people now.
I understand people's aversion to the #ifdefs in the code, but if the changes
are made in a sane way, it can still be clean and easy to maintain. It's
worth it to add a little complexity (particularly as an option) to add a
feature that people will be demanding in the relatively near future. It
might be a good idea to wait for 2.5, tho...
Brad Boyer
[EMAIL PROTECTED]
P.S.: No, I have no personal reason to need any of this 64 bit filesystem
stuff. Just trying to point out possibilities. Don't expect me to actually
be writing this stuff...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 64-bit block sizes on 32-bit systems
Steve Lord wrote:
Just a brief add to the discussion, besides which I have a vested interest
in this!
I'll add my little comments as well, and hopefully not start a flamewar... :)
[snip comments about blocksize, etc.]
Here's a real-life example of something that most of you will probably hate
me for mentioning:
HFS uses variable sized blocks (made up of multiple 512 byte sectors), but
stores block numbers as a 16 bit value. (I know, everyone will say, "We're
talking about moving from 32 to 64 bits." Keep listening.) This gave great
performance on the then current massive storage of a 20M drive. However,
when it became possible to get the absolutely gigantic hard drive of 1G,
it became more and more obvious that it was a drawback that was causing
a huge amount of wasted space. Apple had to design a new filesystem (HFS+)
that was able to represent blocks with a 32 bit number to overcome the
effective limitation on how big a filesystem could be. It's getting to
the point now that it's easily possible to put together a disk array that
is large enough that even referring to blocks with a 32 bit value requires
relatively large blocks. I don't know if we have very many filesystems that
would support this feature, but it will become important a lot sooner than
anyone may be thinking.
Obviously this case isn't a perfect fit for the situation, since HFS was
designed to be read by 32 bit machines, and the upgrade to 32 bits didn't
give a CPU penalty, just a bus bandwidth problem. Also, I'm coming from
a platform that actually can do a decent job of 64 bit, unlike x86, but
we shouldn't disallow people from doing bigger and better things. It's
become very popular lately to position Linux as an enterprise-ready system,
and this is something that will be expected. People will want to access
a multi-TB database as a single file, as well as other things that may
seem crazy to most people now.
I understand people's aversion to the #ifdefs in the code, but if the changes
are made in a sane way, it can still be clean and easy to maintain. It's
worth it to add a little complexity (particularly as an option) to add a
feature that people will be demanding in the relatively near future. It
might be a good idea to wait for 2.5, tho...
Brad Boyer
[EMAIL PROTECTED]
P.S.: No, I have no personal reason to need any of this 64 bit filesystem
stuff. Just trying to point out possibilities. Don't expect me to actually
be writing this stuff...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
