Тут проблема в том, что в современных процессорах (или даже точнее 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 ... противопоказан.
Ха-ха! Но по-моему вы код изменений (возможно кроме третьего) просто не читали.
Не знаю, что там за параллели, Andy ещё со школы прицепилось, тогда ни о футболисте, ни обо мне ещё свет не знал.
Относительной адресации не было, а переходы были, такие дела.
Тут проблема в том, что в современных процессорах (или даже точнее 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 ...противопоказан.