- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 7 2020
Apr 6 2020
Generally looks good to me, especially if we just test locking. For genera-purpose testing would be good to test master election, failover, etc.
Apr 2 2020
Apr 1 2020
Mar 27 2020
Mar 26 2020
Mar 19 2020
Mar 18 2020
Mar 16 2020
Mar 13 2020
Mar 12 2020
Mar 10 2020
Mar 5 2020
Mar 4 2020
Mar 3 2020
Feb 28 2020
I am OK with that, but I think it can be too easy to forget, same as wrong value is set without understanding now. I am thinking whether introduction of some special constant value for initiator_id equal to UINT_MAX or something could be more explicit?
In D23852#524734, @avg wrote:I would expect that if an initiator can also be a target then its target ID -- which, if I understand correctly, you suggest to be treated as an initiator ID -- would be from a different namespace than IDs of its targets.
Feb 27 2020
It is not a problem of UINT_MAX, it is a problem to ignore potentially correct reported value.
I agree with everything you say we should do. But we are not there yet, and until that time SIMs have to keep some sort of mapping table for CAM to use. From the CAM point now all target IDs of the SCSI domain the HBA is connected to, including the initiator_id are from that mapping table. I am not sure what exactly makes no sense to you in my descrintion of how things are working for FC now and why exactly the same is not applicable to SAS to add this dirty hack?
I have no objections, but it would be good to request review from some port committers.
The patch will make XPT_SCAN_TGT/XPT_SCAN_BUS to scan target they should not.
As I have told, SAS may also work as target, we just miss respective SIM. And the code skipping the initiaror_id during scan allows to not scan own target, if we ever have non-FC targets. What is so difficult in fixing few SAS SIMs to report initiator_id out of the range of valid initiator role targets?
I think it is a wrong way to go. While specific initiator ID value has sense only on parallel SCSI and loop mode FC and is obsolete these days, the idea of having some id reserved for the local HBA itself makes a lot of sense for FC now, when isp(4) driver can operate both initiator and target role same time, and the initiator id is used to represent target role periphs, while other ids are used rot initiator role. Such concepts looks totally valid to me. Even though we do not have SAS target driver (I dreamed about it for years), I don't think we should make it impossible instead of trivially fixing few drivers.
Feb 26 2020
Feb 25 2020
Feb 22 2020
Feb 21 2020
Feb 20 2020
Feb 18 2020
Feb 14 2020
Feb 11 2020
Feb 8 2020
Feb 7 2020
Hi. Does the Hygon really have only one AHCI ID where AMD had 5?
Feb 6 2020
I won't object too much, but first addition of quite specialized command and then workaround for it does not make me particularly happy.
I would honestly prefer drivers to report reasonable errors on unknown commands. That would fix the issue once and for all.
Feb 5 2020
Feb 4 2020
Looks good to me.
I am not sure what is the point of atomic there, except may be preventing compiler from optimizing it out, if that can happen somehow. Otherwise it looks fine to me. I don't remember the interrupt teardown semantics here to say whether use-after-free is possible, but I agree with @gallatin that flags may change in run time, causing epoch leak, so this code must be here.
Feb 3 2020
Jan 30 2020
Jan 28 2020
I have no objections, other than I would not use braces for the if's, or at least put the opening one in the first case on the same like, as Ryan proposed.