"766a65a5" (history) in projects: freebsd

Project(s)

Full Search
Definition
Symbol
File Path
History
Type

Searched hist:"766 a65a5" (Results 1 – 3 of 3) sorted by relevance

/freebsd/sys/dev/isp/
H A D	ispvar.h	766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
H A D	isp.c	766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
H A D	isp_freebsd.c	766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too. 766a65a5 Sun Jul 05 02:09:46 GMT 2015 Alexander Motin <mav@FreeBSD.org> Remove extra level of target ID indirection (isp_dev_map). FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.