lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49009EDA.2030707@ru.mvista.com>
Date:	Thu, 23 Oct 2008 19:57:14 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] IDE updates #4

Hello, I wrote:

>>>> and number of new submitted patches is < 10 (I'll take
>>>> care of fixing them up, ditto for all other new stuff that will be 
>>>> using old
>>>> naming scheme).

>>>    Thanks for clarifying this.
>>>    This rename only added more uncertainty for my pending patchset 
>>> (which had been already dependant on at least TX4939 driver which 
>>> keeps being recast by Atsushi and being stale in pata-2.6 series) as 
>>> I can't predict when you and Linus will merge the changes and this is 
>>> getting on my nerves, as I don't have time on any extra rework and 
>>> I'm running out of time with the submission. I know I should have 
>>> done this earlier and     

>> Maybe some parts could be submitted separately?
>> (so keeping them up-to-date in pata-2.6 would be my task)

>   2 (maybe even 3) out of 4 can be but that doesn't make much sense 
> already (and would incur the patch reordering for me) -- the best thing 
> you can do is to merge ASAP the last verison of TX4939 which has my ACK.
> I'm not sure about TX4938 driver yet -- will look at it after some sleep...

    Still haven't looked at it... too little sleep and incuring headache. :-/

>> Also I didn't know anything about your patchset and its
>> dependency on TX4939, otherwise I'll be pushing things in

>   The patchset consists of a large patch moving read_sff_dma_status() to 
> its porper place, one small preparatory patch, and 2 followup patches, 
> so unfortunately it's dependent on TX4939 in its main patch (worse, the 
> relevant part of this driver has changed after your last merged driver 
> version)...

>> different order or even skip this pull request if needed
>> (TX493x drivers are new stuff and were still under review,
>> such things can be also submitted after the merge window
>> closes so they were given the lowest priority).

>   Unfortunately, that driver has been submitted first back 9/09, long 
> before my patchset was even created, so the dependence was just natural.

    I could also rip out TX4939 part from the patch and leave Atsushi to deal 
with the fallout (though I could give him the ripped out part to simply be 
merged to the driver) if you would queue my patchset ahead of the driver. 
Though I feel it's too late now for my patchset to get into 2.6.28 the way 
things have been happening... :-/

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ