lkmm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Szőke Benjamin" <egyszeregy@freemail.hu>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	paulmck@kernel.org, stern@rowland.harvard.edu,
	parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org,
	npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
	luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com,
	joel@joelfernandes.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, lkmm@lists.linux.dev
Subject: Re: [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem.
Date: Tue, 12 Nov 2024 11:06:05 +0100	[thread overview]
Message-ID: <9ecdbe98-666b-4467-85f5-7f9bc01788c2@freemail.hu> (raw)
In-Reply-To: <ZzKpK_9nxh4Qg6mW@tardis.local>

2024. 11. 12. 2:02 keltezéssel, Boqun Feng írta:
> On Tue, Nov 12, 2024 at 12:21:51AM +0100, Sz"oke Benjamin wrote:
>> 2024. 11. 11. 23:00 keltezéssel, Linus Torvalds írta:
>>> On Mon, 11 Nov 2024 at 13:15, Sz"oke Benjamin <egyszeregy@freemail.hu> wrote:
>>>>
>>>> There is a technical issue in the Linux kernel source tree's file naming/styles
>>>> in git clone command on case-insensitive filesystem.
>>>
>>> No.
>>>
>>> This is entirely your problem.
>>>
>>> The kernel build does not work, and is not intended to work on broken setups.
>>>
>>> If you have a case-insensitive filesystem, you get to keep both broken parts.
>>>
>>> I actively hate case-insensitive filesystems. It's a broken model in
>>> so many ways. I will not lift a finger to try to help that
>>> braindamaged setup.
>>>
>>> "Here's a nickel, Kid. Go buy yourself a real computer"
>>>
>>>                Linus
>>
>>
>> In this patch my goal is to improve Linux kernel codebase to able to
>> edit/coding in any platform, in an IDE which has a modern GUI.
>>
>> Chillout, i am not so stupid to compile kernel on this "braindamaged setup",
>> I just like to edit the code and manage it by git commands.
>>
> 
> Then you just need to create a case-sensitive partition, no? What's the
> *technical* issue of doing that? And that cannot be more challenging
> than testing your kernel changes, right? So it won't raise the bar of a
> potential serious kernel contributer.
> 

It is easy to say just need a case-sensitive partition, and sure it can be 
configurable but for example on Windows, admin rights needed for it, which is 
not available in 90% for a workstation machine in an universitiy or a general 
company.


>> So, this is a tipical Braindamaged setup in 2024 for Generation of a half of
>> Y (like me), Z and Alpha developers.
>>
>> Windows or MacOS system
>> - Visual Studio Code for coding
>>      - Git for manage kernel source
>>      - IntelliSense in coding
>>      - Live coding with other developers
>>
>> Linux remote server
>> - Visual Studio Code remote SSH extension/connection for Linux server
>>      - Sync kernel workdir with remote Ubuntu/Debian/RHEL Linux server
>>      - Remote SSH compile for X86_64, ARM64 etc ...
>>      - Download the build result
>>
> 
> How do you know it's "typical"? I just googled it and confirmed I'm a
> Gen Y ;-) and I'm not using vscode or any IDE, a lot of Gen Y, Z and
> Alpha developers I know either use Linux on their desktop/laptop or they
> don't use IDEs. May my experience suffice to say it's not typical? Or is
> it the case where I thought me and my friends are the whole world? ;-)
> 
>> Instead of Visual Studio Code it can be possible to use JetBrains, Eclipse
>> and so on any other modern IDE. The actual limitation is only, that there is
>> a filename issue in the Linux kernel source with
>> "Z6.0+pooncelock+poonceLock+pombonce.litmus", why git clone is failed to
>> work well in this case-insensitive OSs.
> 
> They are not "case-insensitive" OSes, they support case-sensitive
> filesystems, and they support them for a reason, so just use them. With
> your changes, it may be OK at clone time, but as soon as you do some
> serious development involving `git bisect`, you might be very frustated
> that your setup doesn't work.
> 
> So your solution is incompleted (not handling the git history), and your
> goal is a bit personalized: it's only useful to people who want to
> read/edit Linux code without running it and don't want to use a
> case-sensitive filesystem, and that's not very persuasive. I don't think
> we can accept the solution or commit to that goal.
> 

I know the superhero operation may not possible but, i like to edit the code, i 
like to browse the code by mouse clicking easily, how possible in a limited way 
in https://elixir.bootlin.com/linux/v6.11.7/source. I like to get a well work 
IntelliSense and later Copilot AI feature.

In my use-case i do it for ARM64 embedded boards to make patches and 
modifications for my Yocto projects, it means i will run and test my kernel 
build on my target board only, which was downloaded from the remote compiler 
machine after my remote build.

As i saw that in some Youtube coding persons and cahnnels and see colleagues and 
friends, young developers more like to use IDE/GUI in Windows or MacOS for just 
coding/editing and do the basics via git, then use any SSH connection/solution 
to compile the things in remotely then test it in Qemu or a real remote 
machine/board.

In 2024 trend is for multiplatform IDEs like Eclipse, VScode and so on ... SW 
Projects also need to support the minimum possibilities to able to edit and 
manage them in multiplatform mode, otherwise this techs improvments makes no 
sense and they never take adventage of their new IDEs benefits for these 
projects in the future.

> Regards,
> Boqun


  reply	other threads:[~2024-11-12 10:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11 16:42 [PATCH] tools/memory-model: Fix litmus-tests's file names for case-insensitive filesystem egyszeregy
2024-11-11 16:54 ` Paul E. McKenney
2024-11-11 18:52   ` Szőke Benjamin
2024-11-11 19:22     ` Paul E. McKenney
2024-11-11 19:56       ` Szőke Benjamin
2024-11-11 20:29         ` Paul E. McKenney
2024-11-11 21:15           ` Szőke Benjamin
2024-11-11 21:23             ` Boqun Feng
2024-11-11 21:39               ` Szőke Benjamin
2024-11-11 21:44                 ` Boqun Feng
2024-11-11 21:52                 ` Paul E. McKenney
2024-11-11 22:00             ` Linus Torvalds
2024-11-11 23:21               ` Szőke Benjamin
2024-11-12  1:02                 ` Boqun Feng
2024-11-12 10:06                   ` Szőke Benjamin [this message]
2024-11-12 16:43                     ` Paul E. McKenney
2024-11-12 16:56                       ` Boqun Feng
2024-11-12  0:59             ` Alan Stern
2024-11-12  4:20               ` Paul E. McKenney
2024-11-12 15:35                 ` Alan Stern
2024-11-12 18:26                   ` Paul E. McKenney
2024-11-12 20:20                     ` Alan Stern
2024-11-12 21:53                       ` Paul E. McKenney
2024-12-12 23:09                         ` Szőke Benjamin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9ecdbe98-666b-4467-85f5-7f9bc01788c2@freemail.hu \
    --to=egyszeregy@freemail.hu \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkmm@lists.linux.dev \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).