Re: A desktop environment[1] kernel wishlist
On Mon, Oct 27, 2014 at 03:28:04PM +0100, Bastien Nocera wrote: > On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote: > > On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote: > > > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote: > > > > On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera > > > > wrote: > > > > >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm, > > > > >> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm) > > > > >> documentation' > > > > >> > > > > >> Can you expand more on the rational for the need here? Is this for UI > > > > >> for power debugging, or something else? > > > > > > > > > > No, it would be used for automating backups, or implementing > > > > > suspend->hibernation transitions. For example, right before the > > > > > machine > > > > > suspends, I would schedule it to wake up in a hour. If I get woken up > > > > > by > > > > > the rtc alarm (and not by the user through a lid open), I might: > > > > > - check that I'm plugged into the AC, it's night, and in the vicinity > > > > > of > > > > > the server that handles my backups and so backup the system. > > > > > - check whether the battery is low, and hibernate the machine (if it > > > > > supports it, obviously). > > > > > > > > > > We cannot do that if we can't make out whether the wake-up came from a > > > > > user action, or the alarm we set. > > > > > > > > I suspect wakeup type reporting is maybe not the best way to go about > > > > this, since there may be a number of causes for wakeups and they can > > > > arrive closely together in different orders, which can result in > > > > races. > > > > > > > > For instance, if the machine suspends, and sets an alarm to be woken > > > > up at midnight to do a backup, if the user resumes their laptop at > > > > 11:59:59, should the backup still proceed at midnight? > > > > > > No. And I would expect that we would get a wake up type of "power > > > button" or "lid open" in this case. > > > > I have been using something like this for the last 7 years or so. > > The relevant inputs are: > > > > 1. is the user present (is there recent input on HID devices, > > keyboard/mouse, but ignore devices like light sensors, 3D > > accelerometers, and ACPI virtual keys)? > > If the user woke the machine up through the power button, you wouldn't > see that from user-space. You could detect that the lid was opened, > because you have state. > > > 2. which network connection(s) are available to reach the > > backup server? > > > > 3. how much power is available (if on battery, how much run > > time left?) > > > > 4. what is the policy (do backups happen at a specific time > > of day, or whenever they can?) > > > > 5. was a backup completed successfully in the last N hours? > > > > Note the absence of any information about the cause of recent > > suspend/resume activity, or any input from suspend/resume at all. > > How do I tell my environment not to wake the screen up when the machine > was woken up by an alarm I scheduled to launch a backup? Lid closed? Screen off (nobody can see it, it wastes power on battery, and lengthens charge time on AC). Lid open and user input? Screen on. Lid open and user disabled time-based screen power saving? Screen on. These are not symmetrical. To wake up the screen, the screen needs to be visible, and the policy conditions to wake up the screen need to be met. Spontaneously firing up a backlight at full power in a dark room in the middle of the night may not be appreciated by the system owner. I could see the utility of capturing ACPI state here, but only as a way to sense the "user present" condition. > Or not to > resume audio playback when I get woken up to handle network events > (through connected suspend, or Wake-On-(Wireless-)LAN)? Audio playback can wait for evidence of user presence too (unless we're implementing an alarm clock, and need to wake up the audio ourselves--but we'd know that because of the time). signature.asc Description: Digital signature
Re: A desktop environment[1] kernel wishlist
On Mon, Oct 27, 2014 at 03:28:04PM +0100, Bastien Nocera wrote: On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote: On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote: On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote: On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera had...@hadess.net wrote: As for: 'Export of wake reason when the system wakes up (rtc alarm, lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm) documentation' Can you expand more on the rational for the need here? Is this for UI for power debugging, or something else? No, it would be used for automating backups, or implementing suspend-hibernation transitions. For example, right before the machine suspends, I would schedule it to wake up in a hour. If I get woken up by the rtc alarm (and not by the user through a lid open), I might: - check that I'm plugged into the AC, it's night, and in the vicinity of the server that handles my backups and so backup the system. - check whether the battery is low, and hibernate the machine (if it supports it, obviously). We cannot do that if we can't make out whether the wake-up came from a user action, or the alarm we set. I suspect wakeup type reporting is maybe not the best way to go about this, since there may be a number of causes for wakeups and they can arrive closely together in different orders, which can result in races. For instance, if the machine suspends, and sets an alarm to be woken up at midnight to do a backup, if the user resumes their laptop at 11:59:59, should the backup still proceed at midnight? No. And I would expect that we would get a wake up type of power button or lid open in this case. I have been using something like this for the last 7 years or so. The relevant inputs are: 1. is the user present (is there recent input on HID devices, keyboard/mouse, but ignore devices like light sensors, 3D accelerometers, and ACPI virtual keys)? If the user woke the machine up through the power button, you wouldn't see that from user-space. You could detect that the lid was opened, because you have state. 2. which network connection(s) are available to reach the backup server? 3. how much power is available (if on battery, how much run time left?) 4. what is the policy (do backups happen at a specific time of day, or whenever they can?) 5. was a backup completed successfully in the last N hours? Note the absence of any information about the cause of recent suspend/resume activity, or any input from suspend/resume at all. How do I tell my environment not to wake the screen up when the machine was woken up by an alarm I scheduled to launch a backup? Lid closed? Screen off (nobody can see it, it wastes power on battery, and lengthens charge time on AC). Lid open and user input? Screen on. Lid open and user disabled time-based screen power saving? Screen on. These are not symmetrical. To wake up the screen, the screen needs to be visible, and the policy conditions to wake up the screen need to be met. Spontaneously firing up a backlight at full power in a dark room in the middle of the night may not be appreciated by the system owner. I could see the utility of capturing ACPI state here, but only as a way to sense the user present condition. Or not to resume audio playback when I get woken up to handle network events (through connected suspend, or Wake-On-(Wireless-)LAN)? Audio playback can wait for evidence of user presence too (unless we're implementing an alarm clock, and need to wake up the audio ourselves--but we'd know that because of the time). signature.asc Description: Digital signature
Re: A desktop environment[1] kernel wishlist
On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote: > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote: > > On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera wrote: > > >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm, > > >> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm) > > >> documentation' > > >> > > >> Can you expand more on the rational for the need here? Is this for UI > > >> for power debugging, or something else? > > > > > > No, it would be used for automating backups, or implementing > > > suspend->hibernation transitions. For example, right before the machine > > > suspends, I would schedule it to wake up in a hour. If I get woken up by > > > the rtc alarm (and not by the user through a lid open), I might: > > > - check that I'm plugged into the AC, it's night, and in the vicinity of > > > the server that handles my backups and so backup the system. > > > - check whether the battery is low, and hibernate the machine (if it > > > supports it, obviously). > > > > > > We cannot do that if we can't make out whether the wake-up came from a > > > user action, or the alarm we set. > > > > I suspect wakeup type reporting is maybe not the best way to go about > > this, since there may be a number of causes for wakeups and they can > > arrive closely together in different orders, which can result in > > races. > > > > For instance, if the machine suspends, and sets an alarm to be woken > > up at midnight to do a backup, if the user resumes their laptop at > > 11:59:59, should the backup still proceed at midnight? > > No. And I would expect that we would get a wake up type of "power > button" or "lid open" in this case. I have been using something like this for the last 7 years or so. The relevant inputs are: 1. is the user present (is there recent input on HID devices, keyboard/mouse, but ignore devices like light sensors, 3D accelerometers, and ACPI virtual keys)? 2. which network connection(s) are available to reach the backup server? 3. how much power is available (if on battery, how much run time left?) 4. what is the policy (do backups happen at a specific time of day, or whenever they can?) 5. was a backup completed successfully in the last N hours? Note the absence of any information about the cause of recent suspend/resume activity, or any input from suspend/resume at all. Most of the inputs are used for table lookup with a bit of logic for dependent configuration parameters. e.g. from input #2, if the network connection is not home or office, use a different threshold for the amount of battery power required by input #3, assuming that when I'm in those specific places I am never more than 5 minutes away from AC power. In my setup a daemon evaluates all the input conditions whenever any of them change, and if the result is "machine should sleep" then it simulates #4 over time, sets an alarm for the next time "machine should not sleep" is asserted, and goes to sleep. If the next wakeup event is less than 60 seconds in the future, we might miss the wakeup alarm, so we just stay on. The daemon controls the backup process (and dozens of other power-state-dependent processes) with freezer cgroups. The backup process knows nothing about power management or scheduling (nor should it), it is simply running, frozen, or not running according to the current conditions and the table. All five inputs are relevant. I don't want backups while I'm using the machine as a desktop because of the latency impact on disk and network; however, when I stop to get a coffee, the backups can proceed until I get back. If the only network available incurs per-bit usage charges or it is a shared busy network with no excess capacity, there will be no backups regardless of the other conditions. If the machine has less than six hours of battery power and no AC feed, there are no backups. The best part is that in this scheme the backups can be scheduled opportunistically, i.e. whenever the machine is awake and required resources are abundant or underutilized, so by the time midnight rolls around there are rarely any outstanding backups left to do, and the machine just sleeps straight through the night. The same schema gets used for other processes like web browsers, but with different values (e.g. the web browser runs only when there is a network connection and one of AC power or recent user input, and is frozen at other times so that the battery isn't wasted rotating banner ads that nobody is looking at). > > What happens > > if the user starts to use their machine at 12:00:01? > > I would expect the backup to stop and be tried again later. Suspend/resume has nothing to do with this. Backups should treat suspend state like a routine transient network failure. If I suspend my laptop because I'm moving from one meeting room to another, the TCP connections used by the
Re: A desktop environment[1] kernel wishlist
On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote: On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote: On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera had...@hadess.net wrote: As for: 'Export of wake reason when the system wakes up (rtc alarm, lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm) documentation' Can you expand more on the rational for the need here? Is this for UI for power debugging, or something else? No, it would be used for automating backups, or implementing suspend-hibernation transitions. For example, right before the machine suspends, I would schedule it to wake up in a hour. If I get woken up by the rtc alarm (and not by the user through a lid open), I might: - check that I'm plugged into the AC, it's night, and in the vicinity of the server that handles my backups and so backup the system. - check whether the battery is low, and hibernate the machine (if it supports it, obviously). We cannot do that if we can't make out whether the wake-up came from a user action, or the alarm we set. I suspect wakeup type reporting is maybe not the best way to go about this, since there may be a number of causes for wakeups and they can arrive closely together in different orders, which can result in races. For instance, if the machine suspends, and sets an alarm to be woken up at midnight to do a backup, if the user resumes their laptop at 11:59:59, should the backup still proceed at midnight? No. And I would expect that we would get a wake up type of power button or lid open in this case. I have been using something like this for the last 7 years or so. The relevant inputs are: 1. is the user present (is there recent input on HID devices, keyboard/mouse, but ignore devices like light sensors, 3D accelerometers, and ACPI virtual keys)? 2. which network connection(s) are available to reach the backup server? 3. how much power is available (if on battery, how much run time left?) 4. what is the policy (do backups happen at a specific time of day, or whenever they can?) 5. was a backup completed successfully in the last N hours? Note the absence of any information about the cause of recent suspend/resume activity, or any input from suspend/resume at all. Most of the inputs are used for table lookup with a bit of logic for dependent configuration parameters. e.g. from input #2, if the network connection is not home or office, use a different threshold for the amount of battery power required by input #3, assuming that when I'm in those specific places I am never more than 5 minutes away from AC power. In my setup a daemon evaluates all the input conditions whenever any of them change, and if the result is machine should sleep then it simulates #4 over time, sets an alarm for the next time machine should not sleep is asserted, and goes to sleep. If the next wakeup event is less than 60 seconds in the future, we might miss the wakeup alarm, so we just stay on. The daemon controls the backup process (and dozens of other power-state-dependent processes) with freezer cgroups. The backup process knows nothing about power management or scheduling (nor should it), it is simply running, frozen, or not running according to the current conditions and the table. All five inputs are relevant. I don't want backups while I'm using the machine as a desktop because of the latency impact on disk and network; however, when I stop to get a coffee, the backups can proceed until I get back. If the only network available incurs per-bit usage charges or it is a shared busy network with no excess capacity, there will be no backups regardless of the other conditions. If the machine has less than six hours of battery power and no AC feed, there are no backups. The best part is that in this scheme the backups can be scheduled opportunistically, i.e. whenever the machine is awake and required resources are abundant or underutilized, so by the time midnight rolls around there are rarely any outstanding backups left to do, and the machine just sleeps straight through the night. The same schema gets used for other processes like web browsers, but with different values (e.g. the web browser runs only when there is a network connection and one of AC power or recent user input, and is frozen at other times so that the battery isn't wasted rotating banner ads that nobody is looking at). What happens if the user starts to use their machine at 12:00:01? I would expect the backup to stop and be tried again later. Suspend/resume has nothing to do with this. Backups should treat suspend state like a routine transient network failure. If I suspend my laptop because I'm moving from one meeting room to another, the TCP connections used by the backups should survive and backups will continue as soon as the machine wakes up. If
2.2.17, Promise FastTrak66/PDC20262, ugly patches to enable second interface
I started with this:
Software:
Linux 2.2.17
Unified IDE 6.30 (ide.2.2.17.all.2904.patch.bz2)
Linux raid 0.90 (raid-2.2.17-A0)
Hardware:
Dual PIII-550
2 x PIIX4 IDE interfaces on motherboard
2 x Promise FastTrak 66 (PDC20262) in PCI slots
.config and dmesg available on request.
I could not get the second IDE interface on two Promise FastTrak66
(PDC20262, (C) 1998, BIOS revision 1.30) controllers to work until I
applied the following patch:
--- drivers/block/ide-pci.c Mon Oct 23 17:45:39 2000
+++ /tmp/kludgedMon Oct 30 18:31:47 2000
@@ -562,8 +562,6 @@
for (port = 0; port <= 1; ++port) {
unsigned long base = 0, ctl = 0;
ide_pci_enablebit_t *e = &(d->enablebits[port]);
- if (e->reg && (pci_read_config_byte(dev, e->reg, ) || (tmp &
e->mask) != e->val))
- continue; /* port not enabled */
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT366) && (port) && (class_rev <
0x03))
return;
if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE || (dev->class & (port
? 4 : 1)) != 0) {
This made the second IDE interface on both Promise cards work.
Am I missing something?
The patch disregards the enabled flag on the Promise card's second
IDE interface. Any idea why is that interface is not marked enabled?
More importantly, why is it not enabled on my cards, but apparently
enabled on all of the PDC20262 cards previously mentioned in lkml?
The second IDE on these cards certainly seems to be enabled, because
it's operating in UDMA66 mode through a raid5 sync, lots of md5summing,
and a bonnie or two:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
raid5x5 1536 7465 98.3 29956 35.1 16710 40.1 8575 96.5 50594 35.6 251.4 2.6
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.17, Promise FastTrak66/PDC20262, ugly patches to enable second interface
I started with this:
Software:
Linux 2.2.17
Unified IDE 6.30 (ide.2.2.17.all.2904.patch.bz2)
Linux raid 0.90 (raid-2.2.17-A0)
Hardware:
Dual PIII-550
2 x PIIX4 IDE interfaces on motherboard
2 x Promise FastTrak 66 (PDC20262) in PCI slots
.config and dmesg available on request.
I could not get the second IDE interface on two Promise FastTrak66
(PDC20262, (C) 1998, BIOS revision 1.30) controllers to work until I
applied the following patch:
--- drivers/block/ide-pci.c Mon Oct 23 17:45:39 2000
+++ /tmp/kludgedMon Oct 30 18:31:47 2000
@@ -562,8 +562,6 @@
for (port = 0; port = 1; ++port) {
unsigned long base = 0, ctl = 0;
ide_pci_enablebit_t *e = (d-enablebits[port]);
- if (e-reg (pci_read_config_byte(dev, e-reg, tmp) || (tmp
e-mask) != e-val))
- continue; /* port not enabled */
if (IDE_PCI_DEVID_EQ(d-devid, DEVID_HPT366) (port) (class_rev
0x03))
return;
if ((dev-class 8) != PCI_CLASS_STORAGE_IDE || (dev-class (port
? 4 : 1)) != 0) {
This made the second IDE interface on both Promise cards work.
Am I missing something?
The patch disregards the enabled flag on the Promise card's second
IDE interface. Any idea why is that interface is not marked enabled?
More importantly, why is it not enabled on my cards, but apparently
enabled on all of the PDC20262 cards previously mentioned in lkml?
The second IDE on these cards certainly seems to be enabled, because
it's operating in UDMA66 mode through a raid5 sync, lots of md5summing,
and a bonnie or two:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
raid5x5 1536 7465 98.3 29956 35.1 16710 40.1 8575 96.5 50594 35.6 251.4 2.6
--
Zygo Blaxell (Laptop) [EMAIL PROTECTED]
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article <[EMAIL PROTECTED]>, Eli Carter <[EMAIL PROTECTED]> wrote: >Mitchell Blank Jr wrote: >> Daniel Quinlan wrote: >> > "Version" - the base kernel version. For example, "2.4.0-test8-pre1". >> > The web page will list valid version strings. >> Ideally this should be overridable for patches marked experimental, since >> they might be to some modified kernel. Of course you wouldn't do an >> test for applyability :-) > >Yes you can. Use the "Requires" identifier to add all the previous >patches first. But if the patch for the prerequisite modification isn't >available, what is the point of submitting the patch? If both patches are submitted at near the same time, the prerequisite patch may not arrive until after its dependents; in that case, you'd want the patch tracking system to hold on to the dependents until the prerequisite showed up. Consider the following scenario: developer A makes a patch P. developer A sends a copy of P to the patch tracking system. developer A CC's a copy of P to developer B in the same email. the copy of P for the patch tracking system enters a Microsoft Exchange email server during a Visual Basic Scripting Host virus incident, and is delayed by 48 hours. developer B fixes a bug in P, making patch Q. developer B submits Q to patch tracking system with "Requires: P" (assuming B has some identifier for P; see below for ideas on how to do this). the patch tracking system receives Q from B. To cope with the scenario outlined above, in addition to a numeric ID assigned by the patch server, the server should support reference to a patch by the MD5 hash of the patch text, or by message-IDs in email headers when patches are submitted. When the patch server can unambiguously translate one of those into a locally unique ID for the patch, it should do so, but leave the original specification in its internal database so that the patch can be meaningfully exported again. I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch text (i.e. the stuff you actually input to 'patch') as the actual patch identifier, and make the other ID forms search queries that ultimately resolve the MD5 hash. This has the advantage of allowing for a single globally unique identifier for all patches even if there are multiple kernel patch servers operated by different groups. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article <[EMAIL PROTECTED]>, Jeff Garzik <[EMAIL PROTECTED]> wrote: >When I sent Linus ten or twenty patches, that means I'm filling in ten >to twenty e-mail templates, yum :) Presumably that part of the process can be automated: $ cd /usr/src/linux $ ./scripts/submit-patch /tmp/patch-1 /tmp/patch-2 /tmp/patch3... The first time you'd run this hypothetical script, it would ask for template field values and offer to remember the ones that don't change often, such as the architecture you're working on. Presumably it would work in batch mode, too, if you had several related patches. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article [EMAIL PROTECTED], Jeff Garzik [EMAIL PROTECTED] wrote: When I sent Linus ten or twenty patches, that means I'm filling in ten to twenty e-mail templates, yum :) Presumably that part of the process can be automated: $ cd /usr/src/linux $ ./scripts/submit-patch /tmp/patch-1 /tmp/patch-2 /tmp/patch3... The first time you'd run this hypothetical script, it would ask for template field values and offer to remember the ones that don't change often, such as the architecture you're working on. Presumably it would work in batch mode, too, if you had several related patches. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
In article [EMAIL PROTECTED], Eli Carter [EMAIL PROTECTED] wrote: Mitchell Blank Jr wrote: Daniel Quinlan wrote: "Version" - the base kernel version. For example, "2.4.0-test8-pre1". The web page will list valid version strings. Ideally this should be overridable for patches marked experimental, since they might be to some modified kernel. Of course you wouldn't do an test for applyability :-) Yes you can. Use the "Requires" identifier to add all the previous patches first. But if the patch for the prerequisite modification isn't available, what is the point of submitting the patch? If both patches are submitted at near the same time, the prerequisite patch may not arrive until after its dependents; in that case, you'd want the patch tracking system to hold on to the dependents until the prerequisite showed up. Consider the following scenario: developer A makes a patch P. developer A sends a copy of P to the patch tracking system. developer A CC's a copy of P to developer B in the same email. the copy of P for the patch tracking system enters a Microsoft Exchange email server during a Visual Basic Scripting Host virus incident, and is delayed by 48 hours. developer B fixes a bug in P, making patch Q. developer B submits Q to patch tracking system with "Requires: P" (assuming B has some identifier for P; see below for ideas on how to do this). the patch tracking system receives Q from B. To cope with the scenario outlined above, in addition to a numeric ID assigned by the patch server, the server should support reference to a patch by the MD5 hash of the patch text, or by message-IDs in email headers when patches are submitted. When the patch server can unambiguously translate one of those into a locally unique ID for the patch, it should do so, but leave the original specification in its internal database so that the patch can be meaningfully exported again. I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch text (i.e. the stuff you actually input to 'patch') as the actual patch identifier, and make the other ID forms search queries that ultimately resolve the MD5 hash. This has the advantage of allowing for a single globally unique identifier for all patches even if there are multiple kernel patch servers operated by different groups. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
