Comments 4
Напрашивается серьёзный вопрос прямо по существу темы:
В чём конкретно практический смысл подобной инициативы, если (судя по текусту) компания будет любые изменения и модификации реализовывать силами собственных разработчиков и не предоставлять доступа даже к референсному («на минималках») коду прошивок?
Даже если будет предоставляться доступ к исходным таблицам конфигурации (чего-либо) — этого совсем недостаточно.
И получается, что потенциальный заказчик всё так же полностью зависит от всё того же производителя SSD, его стандартного кода и всех (почти без исключения) сопутствующих багов и нюансов. Любые изменения сложно будет считать «уникальными» или «безопасными», так как что знают двое — знает половина планеты.
Кастомизация SSD в дешёвом сегменте (любые SATA, M.2 SATA, NVMe и в принципе любые SSD «для обычного магазина») на сегодняшний день имеет смысл только тогда, когда потенциальный заказчик сможет собственными силами:
Вот если бы нашёлся производитель, который бы решился реализовать полнофункциональный Firmware SDK, доступный для потенциальных клиентов и дающий возможность оказать влияние и на работу FTL, и на недеструктивную (для данных пользователя) обработку критических ситуаций (BAD_CONTEXT на Intel всех ценовых диапазонов — реально массовая боль), добавлять новый или видоизменять стандартный функционал внутренних счётчиков производительности (S.M.A.R.T. в том числе), на систему журналирования ошибок (GPL логи), и так далее — вот это было бы взрывной инициативой.
И распространить возможности SDK не только на массовый продукт (SATA, SATA M.2), но и на SAS и NVMe.
К огромному сожалению, такая инициатива маловероятна в обозримом будущем, так как потребует невероятно огромной смелости и уверенности в своих продуктах от производителя подобных устройств.
Как идея — да, звучит интересно.
Но в практическую ценность и эффективность в реальных задачах — верится с трудом. К сожалению.
В чём конкретно практический смысл подобной инициативы, если (судя по текусту) компания будет любые изменения и модификации реализовывать силами собственных разработчиков и не предоставлять доступа даже к референсному («на минималках») коду прошивок?
Даже если будет предоставляться доступ к исходным таблицам конфигурации (чего-либо) — этого совсем недостаточно.
И получается, что потенциальный заказчик всё так же полностью зависит от всё того же производителя SSD, его стандартного кода и всех (почти без исключения) сопутствующих багов и нюансов. Любые изменения сложно будет считать «уникальными» или «безопасными», так как что знают двое — знает половина планеты.
Кастомизация SSD в дешёвом сегменте (любые SATA, M.2 SATA, NVMe и в принципе любые SSD «для обычного магазина») на сегодняшний день имеет смысл только тогда, когда потенциальный заказчик сможет собственными силами:
- что-то изменить, улучшить или даже серьёзно модифицировать в референсном дизайне согласно своему собственному тех.заданию и проекту, и самостоятельно принять меры, чтобы этот процесс сохранил коммерческую целесообразность;
- добавить ранее отсутствующий функционал: например, хорошие и реально полезные функции диагностики — это №1, чего не хватает во всех без исключения устройствах хранения данных на сегодняшний день;
- манипуляции с атрибутами S.M.A.R.T. — это прекрасно, но опять же производитель лишь предлагает "что-то сделать по вашему описанию", а именно тут и кроется череда "подводных камней";
- список можно продолжать довольно долго...
Вот если бы нашёлся производитель, который бы решился реализовать полнофункциональный Firmware SDK, доступный для потенциальных клиентов и дающий возможность оказать влияние и на работу FTL, и на недеструктивную (для данных пользователя) обработку критических ситуаций (BAD_CONTEXT на Intel всех ценовых диапазонов — реально массовая боль), добавлять новый или видоизменять стандартный функционал внутренних счётчиков производительности (S.M.A.R.T. в том числе), на систему журналирования ошибок (GPL логи), и так далее — вот это было бы взрывной инициативой.
И распространить возможности SDK не только на массовый продукт (SATA, SATA M.2), но и на SAS и NVMe.
К огромному сожалению, такая инициатива маловероятна в обозримом будущем, так как потребует невероятно огромной смелости и уверенности в своих продуктах от производителя подобных устройств.
Как идея — да, звучит интересно.
Но в практическую ценность и эффективность в реальных задачах — верится с трудом. К сожалению.
Большое спасибо за ваш подробный и конструктивный комментарий. Программа Design-In как раз подразумевает предоставление готового решения под ключ для заказчика, т.е. поможет переложить головную боль по доведению железа до ума на производителя, тем самым экономя собственные ресурсы. Переживать на счет утечек информации третьим лицам не стоит, это можно решить подписанием договора о не разглашении. С Kingston сотрудничают практически все мировые лидеры IT отрасли, например, под крышкой многих ноутбуков можно найти нашу продукцию. Компания дорожит своей репутацией и отношениями с клиентами. Все упомянутые опции как раз можно обозначить в рамках диалога при формировании ТЗ, так же в последствии можно вносить правки.
FW SDK – это палка о двух концах =) предоставляя полный доступ к самостоятельной модификации, производитель лишает себя полноценной возможности гарантировать исправность продукта. В такой ситуации вопросы качества продукции уступают место большим юридическим трудностям.
FW SDK – это палка о двух концах =) предоставляя полный доступ к самостоятельной модификации, производитель лишает себя полноценной возможности гарантировать исправность продукта. В такой ситуации вопросы качества продукции уступают место большим юридическим трудностям.
Про юридические трудности — да, согласен.
Про FW SDK как концепт — и всё-таки, тут больше плюсов, чем минусов.
Ведь нет никакой необходимости раскрывать код ядра и даже основное тело кода FTL (а это львиная часть возможного IP) — их можно поставлять в виде предкомпиленных объектных файлов (ELF) в составе SDK, а гибкость кастомизации обеспечить через API.
Позволю себе напомнить про неудачный опыт практически такой же инициативы, как предлагает Kingston, компанией SandForce (разработчик SSD-контроллеров).
Они тоже сохраняли все модификации и ре-дизайн на своей стороне и под любого желающего готовы были делать практически любые изменения в коде и конфигурациях.
А в результате всё закончилось тем, что на сегодняшний день это самые проблемные из legacy-накопителей SSD как раз в силу того, что существует буквально десятки тысяч уникальных конфигураций и прошивок (малосовместимых или полностью несовместимых между собой), закрытый диагностический режим, огромные проблемы при восстановлении данных и так далее. И проприетарный алгоритм компрессии данных "на лету" тоже показал спорные результаты. И ничего невозможно с этим поделать.
Как неленивый разработчик, я бы предпочёл подписать NDA, получить FW SDK и принять всю дальнейшую ответственность за результат на себя — ведь это был бы некий новый продукт под собственным лейблом, и репутационные риски в случае любой неудачи не перекладываются на компанию-производителя.
Этакий двухуровневый OEM, но почему бы и нет :)
Времена меняются.
С учётом чудовищно низкой надёжности памяти QLC и надвигающегося ужаса в виде PLC — вполне уместно начать предлагать крупным клиентам возможность "поиграть в LEGO" и через FW SDK реализовать свои "хотелки", а производитель предоставит производственные мощности. Все при деле и всем счастье.
Некая форма баланса зон ответственности, чтобы позволить рынку самостоятельно определиться, что важнее — износостойкость, цена или доп.функционал (или их комбинации).
Я высказал исключительно свою личную точку зрения и попытался её обосновать более-менее объективным образом.
Понятное дело, что рынок руководствуется иными принципами и в реальности FW SDK как идея так и останется на уровне мечтаний. Это нормально :)
Про FW SDK как концепт — и всё-таки, тут больше плюсов, чем минусов.
Ведь нет никакой необходимости раскрывать код ядра и даже основное тело кода FTL (а это львиная часть возможного IP) — их можно поставлять в виде предкомпиленных объектных файлов (ELF) в составе SDK, а гибкость кастомизации обеспечить через API.
Позволю себе напомнить про неудачный опыт практически такой же инициативы, как предлагает Kingston, компанией SandForce (разработчик SSD-контроллеров).
Они тоже сохраняли все модификации и ре-дизайн на своей стороне и под любого желающего готовы были делать практически любые изменения в коде и конфигурациях.
А в результате всё закончилось тем, что на сегодняшний день это самые проблемные из legacy-накопителей SSD как раз в силу того, что существует буквально десятки тысяч уникальных конфигураций и прошивок (малосовместимых или полностью несовместимых между собой), закрытый диагностический режим, огромные проблемы при восстановлении данных и так далее. И проприетарный алгоритм компрессии данных "на лету" тоже показал спорные результаты. И ничего невозможно с этим поделать.
Как неленивый разработчик, я бы предпочёл подписать NDA, получить FW SDK и принять всю дальнейшую ответственность за результат на себя — ведь это был бы некий новый продукт под собственным лейблом, и репутационные риски в случае любой неудачи не перекладываются на компанию-производителя.
Этакий двухуровневый OEM, но почему бы и нет :)
Времена меняются.
С учётом чудовищно низкой надёжности памяти QLC и надвигающегося ужаса в виде PLC — вполне уместно начать предлагать крупным клиентам возможность "поиграть в LEGO" и через FW SDK реализовать свои "хотелки", а производитель предоставит производственные мощности. Все при деле и всем счастье.
Некая форма баланса зон ответственности, чтобы позволить рынку самостоятельно определиться, что важнее — износостойкость, цена или доп.функционал (или их комбинации).
Я высказал исключительно свою личную точку зрения и попытался её обосновать более-менее объективным образом.
Понятное дело, что рынок руководствуется иными принципами и в реальности FW SDK как идея так и останется на уровне мечтаний. Это нормально :)
Спасибо за уточнения.
В подобном варианте доступ к прошивке действительно может иметь смысл. Вероятно, в дальнейших итерациях программы Design-In может появиться такая опция.
Несмотря на все погрешности архитектуры и пресловутое сжатие на лету, контроллеры Sandforce пользовались невероятной популярностью долгое время. Большого количества комбинаций NAND и вариаций прошивок хватает сегодня и без них. В том числе этот факт делает Design-In привлекательнее для бизнеса.
В подобном варианте доступ к прошивке действительно может иметь смысл. Вероятно, в дальнейших итерациях программы Design-In может появиться такая опция.
Несмотря на все погрешности архитектуры и пресловутое сжатие на лету, контроллеры Sandforce пользовались невероятной популярностью долгое время. Большого количества комбинаций NAND и вариаций прошивок хватает сегодня и без них. В том числе этот факт делает Design-In привлекательнее для бизнеса.
Sign up to leave a comment.
Kingston Design-In – новые опции для бизнеса