Тут проблема в том, что в современных процессорах (или даже точнее SoC:ах) DMA чаще приватный, а значит вообще не умеет m2m транзакции (только p2m или m2p). Всё зависит как разведены проводки DREQ/DACK и есть ли там арбитр шины (bus master) на обеих сторонах транзакции.
Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time.
То есть по умолчанию 2 года, но может быть и больше, если будет дополнительный интерес и поддержка.
В современных (ну уже как несколько лет :) ) ядрах есть уже свой драйвер (drivers/auxdisplay/panel.c), а кто хочет научиться, тем как раз и впору будет понять как сделать forwardport.
Во-первых, математически rebase vs. merge конечно же разное. Линейность истории, обеспечиваемая первым никак не гарантируется последним.
Во-вторых, чтобы слияние было отдельным изменением в истории — это надо форсировать.
В-третьих, и пожалуй главных, надо отличать публичные ветки от опубликованных, если первые — просто публично доступные, то вторые подразумевают неломание истории.
Учитывая вышесказанное, модель разработки может быть такой, что мейнтенер проекта делает только слияния, то девелоперы в своих топик-ветках спокойно делают смену родительского дерева через git pull --rebase origin master. Глобальное тестирование, понятное дело, работает поверх основной ветки. Разработчики могут в ручном режиме говорить интеграционным тестам прогнать их конкретную публичную (если проект закрытый, то в рамках компании) ветку.
P.S. Может быть пересечёмся в этом году — пообщаемся более детально за пивком :)
В любом языке идиомы являются лакмусовой бумагой на «свой-чужой». Так что не про это выше комментатор говорил. (Кстати, за последние полгода примерно раз-два в неделю обсуждаем с иностранкой русские идиомы, которые для неё все в новинку)
Совершенно верно! Я как-то на один из подобных постов отвечал, что народ путает терминологию, а именно: опубликованные vs. публичные ветки или репозитории. Вот в первых как раз git rebase ... противопоказан.
Ну вы же чушь пишите про git rebase ... Это совершенно мощный инструмент разработчика. Как один из его неявных вариантов git pull --rebase ... Надо, как и везде, понимать что к чему и как использовать инструменты. Например, разработка ядра не могла бы вестись человеческим образом (да и любого проекта, где оперируют сериями патчей) без git rebase ...
Я специально привёл терминологию. Вы путаете опубликованные ветки с публичными. Никто не запрещает делать git rebase в публичных ветках (тем более в приватных), а вот в опубликованных этого делать нельзя. Или ваши пользователи мазохисты до мозга костей, или вы что-то недопонимаете…
Тут проблема в том, что в современных процессорах (или даже точнее SoC:ах) DMA чаще приватный, а значит вообще не умеет m2m транзакции (только p2m или m2p). Всё зависит как разведены проводки DREQ/DACK и есть ли там арбитр шины (bus master) на обеих сторонах транзакции.
То есть по умолчанию 2 года, но может быть и больше, если будет дополнительный интерес и поддержка.
Более того, за эти годы драйвер разросся до целого дерева: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/x86-android-tablets.
Во-первых, математически rebase vs. merge конечно же разное. Линейность истории, обеспечиваемая первым никак не гарантируется последним.
Во-вторых, чтобы слияние было отдельным изменением в истории — это надо форсировать.
В-третьих, и пожалуй главных, надо отличать публичные ветки от опубликованных, если первые — просто публично доступные, то вторые подразумевают неломание истории.
Учитывая вышесказанное, модель разработки может быть такой, что мейнтенер проекта делает только слияния, то девелоперы в своих топик-ветках спокойно делают смену родительского дерева через
git pull --rebase origin master. Глобальное тестирование, понятное дело, работает поверх основной ветки. Разработчики могут в ручном режиме говорить интеграционным тестам прогнать их конкретную публичную (если проект закрытый, то в рамках компании) ветку.P.S. Может быть пересечёмся в этом году — пообщаемся более детально за пивком :)
А ещё можно вспомнить аббревиатуры: BIOS [байос], I/O [ай/о], I²C [айтуси или ай сквэа си],…
P.S. Давайте в личку с этим всем
Ну давно уже применим, только не для всех SoC, конечно, а только в тех, где есть DMA контроллер с поддержкой такого режима.
git rebase ...противопоказан.git remote update -p. Тем не менееgit pull --rebase ...очень полезен.git rebase ...Это совершенно мощный инструмент разработчика. Как один из его неявных вариантовgit pull --rebase ...Надо, как и везде, понимать что к чему и как использовать инструменты. Например, разработка ядра не могла бы вестись человеческим образом (да и любого проекта, где оперируют сериями патчей) безgit rebase ...git rebaseв публичных ветках (тем более в приватных), а вот в опубликованных этого делать нельзя. Или ваши пользователи мазохисты до мозга костей, или вы что-то недопонимаете…