Hello.
Its been a while i spent working with newer kernels. Looking at the tree now
noticed that 2.4.18 etc dont have a include/linux/version.h file?
has its need removed? or does it have an alternate home? I have see that up
until 2.4.9+ we had this and also still notice in redhat releases?
thanks
ashokr
version.h gets automatically generated by the kernel build process.
Dont bother...
i looked at the Makefile and saw this is autogenerated now.
ashokr
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Ashok Raj
Sent: Monday, March 25, 2002 11:45 PM
To: [email protected]
Subject: version.h missing from 2.4.18?
Hello.
Its been a while i spent working with newer kernels. Looking at the tree now
noticed that 2.4.18 etc dont have a include/linux/version.h file?
has its need removed? or does it have an alternate home? I have see that up
until 2.4.9+ we had this and also still notice in redhat releases?
thanks
ashokr
Thanks. Just after i typed the mail i looked the Makefile... sorry for being
a little impatient.!!
I usually add the following to the header file to identify if the build is a
smp/up build. which promped me to find out immediatly before building.
When we work with redhat binaries and sources, we see uname -r gives the
kernel build correctly. for e.g 2.4.7-10smp etc. I fixed the Makefile now to
generate this header.
This becomes handy to identify what kernel is running. Also comes handy to
place the modules in the right directly when modules are build.
Iam not sure if iam the only one doing this, could this be added to the
kernel source tree?
#include <linux/config.h>
#ifndef CONGIG_SMP
#define UTS_RELEASE "2.4.18"
#else
#define UTS_RELEASE "2.4.18smp"
#endif
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of David S. Miller
Sent: Monday, March 25, 2002 11:44 PM
To: [email protected]
Cc: [email protected]
Subject: Re: version.h missing from 2.4.18?
version.h gets automatically generated by the kernel build process.
In article <[email protected]>,
Ashok Raj <[email protected]> wrote:
>Iam not sure if iam the only one doing this, could this be added to the
>kernel source tree?
Use the EXTRAVERSIONS setting in the top level makefile.
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Hello.
I have a question on pci hotplug capability.
when a new device is inserted, the hotplug driver enumerates pci, and if the
driver is already loaded....
for each new device
pci_insert->pci_announce->pci_probe
if i need to remove a device, the pci_remove would be called, but it does
not call to check if the device is ready for removal. If there are other
apps working on this device, how would the hotplug removal be authenticated
before removal?
pci_remove() has no return value, means it cannot fail....
ashokr
On Sat, Mar 30, 2002 at 06:09:56AM -0800, Ashok Raj wrote:
> Hello.
>
> I have a question on pci hotplug capability.
>
> when a new device is inserted, the hotplug driver enumerates pci, and if the
> driver is already loaded....
>
> for each new device
> pci_insert->pci_announce->pci_probe
>
> if i need to remove a device, the pci_remove would be called, but it does
> not call to check if the device is ready for removal. If there are other
> apps working on this device, how would the hotplug removal be authenticated
> before removal?
What function can the pci_hotplug core call to "check"?
> pci_remove() has no return value, means it cannot fail....
This is correct. If the user asks for the device to be powered down, it
will be powered down, even if the driver attached to that device is busy
doing something.
For 2.5, this will probably change, as we will have the option to ask
the driver if it's ok to shutdown (better power management hooks.)
thanks,
greg k-h