The GPL application aeventd is 50K of text, hardly a handful when locked in core, occupying space in multiples on a driver update disk or on initrd image. Imagine the space taken if we had been granted approval to put the full fledged event monitor and r/o portion of array management into core!? We had customers & OEMs that demanded for the application instead of in-core, so can not please everyone, can not manage all levels of rationality. The bonus is that it adds internationalization and because it is an application, can be optional, can be modified without system risks and can be swapped. Why is it so critical that this occupy kernel memory for you (besides the marketing perception)? You are free to integrate aeventd into the driver; anyone can submit a patch. I do not mean that as a threat, Linux can evolve. However, I urge you to read all the accounts surrounding attempts to add CSMI to several of the drivers, an attempt at standards based target and array interrogation and management hooks (Note: the Adaptec version of the aacraid driver still has this integrated despite disapproval on the list, we still have some bruises ;-/ ). Sincerely -- Mark Salyzyn > -----Original Message----- > From: Metathronius Galabant [mailto:m.galabant@xxxxxxxxxxxxxx] > Sent: Friday, October 13, 2006 5:42 AM > To: Salyzyn, Mark > Cc: linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: aacraid driver incomplete regarding info + logging > > > > There is not enough space to waste in the kernel to add > such features, > > and there is a dynamic and complicated relationship between the full > > fledged native and proprietary management applications shipped by > > Are about maybe a handful of informational printk()s really too much? > I'm used to this behaviour from all my machines (gdth, lsi, cciss). > The thing is - because of the driver I had to exchange the adaptec > raid card for something else. > > Cheers, > M > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html